Facing issue in running multiple emulators with AOSP - android-emulator

Problem overview:
After building AOSP with custom emulator(updated default.xml), facing error in executing multiple emulators simultaneously
Command:
Shell1:
emulator -port -no-skin -no-audio -no-window -qemu -device ,addr=,size=
Shell2: (same command to up second emulator)
emulator -port -no-skin -no-audio -no-window -qemu -device ,addr=,size=
Error:
In shell1, no error is faced. Emulator runs fine.
In shell2, ERROR: Running multiple emulators with the same AVD is an experimental feature
Question:
How to correctly create multiple AVDs with AOSP such that multiple emulators can work simultaneously?


With "-read-only" could run multiple emulators simultaneously.
Below commands worked:
Commands:
Shell1:
emulator -port -no-skin -no-audio -no-window -read-only -qemu -device ,addr=,size=
Shell2: (same command to up second emulator)
emulator -port -no-skin -no-audio -no-window -read-only-qemu -device ,addr=,size=
Reference: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/android-building/OUM2KMQuIc4/GRcV4z9_CQAJ

Related

Samsung Tizen Smart TV command Smart Development Bridge < $sdb shell > command returns status is 'closed'. how to enable it.?

My Real Samsung Smart Tizen series 4 TV is running, my build is ready, I am trying to run the following command to run in debug:
$ sdb -s 192.168.0.101:26101 shell 0 execute org.tizen.volume-setting
It returns this :
closed
When I run
$ sdb capability
I have the following output :
imac#iMacs-iMac-2 ~ % sdb capability
secure_protocol:enabled
intershell_support:disabled
filesync_support:pushpull
usbproto_support:disabled
sockproto_support:enabled
syncwinsz_support:enabled
sdbd_rootperm:disabled
rootonoff_support:disabled
encryption_support:disabled
zone_support:disabled
multiuser_support:enabled
cpu_arch:armv7
sdk_toolpath:/home/owner/share/tmp/sdk_tools
profile_name:tv
vendor_name:Samsung
can_launch:tv-samsung
device_name:Tizen
platform_version:5.5
product_version:4.0
sdbd_version:2.2.31
sdbd_plugin_version:3.8.0_TV_REL
sdbd_cap_version:1.0
log_enable:disabled
log_path:/tmp
appcmd_support:disabled
appid2pid_support:enabled
pkgcmd_debugmode:enabled
netcoredbg_support:enabled

eclipse CDT esp-idf build but don't flash

Windows10 eclipse esp-idf latest version 2021-03
With the command line idf.py I can build and flash the esp-idf\examples\get-started\blink programme which run on a ESP32.
In eclipse, the buils works but the run command display in console
Usage: C:\Users\peter\esp-idf\tools\idf.py [OPTIONS] COMMAND1 [ARGS]...
[COMMAND2 [ARGS]...]...
ESP-IDF CLI build management tool. For commands that are not known to
idf.py an attempt to execute it as a build system target will be made.
.... bla bla ...
Can anybody tells me what is wrong ?
Regards

There is a bug in the eclipse/esp-idf launch bar.
The ESP target for esp32 is defined with a Serial Port COM3.
But that info is not used.
If one redefine a new ESP Target with the same serial port under a different name, then the run command will work!
See hereafter for the people interested in the details
cmd.exe /C "cd /D C:\Users\peter\esp-idf\components\esptool_py && C:\Users\peter.espressif\tools\cmake\3.16.4\bin\cmake.exe -D IDF_PATH="C:/Users/peter/esp-idf" -D ESPTOOLPY="C:\Users\peter.espressif\python_env\idf4.2_py3.8_env\Scripts\python.exe C:/Users/peter/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32" -D ESPTOOL_ARGS="--before=default_reset --after=hard_reset write_flash #flash_args" -D WORKING_DIRECTORY="C:/Users/peter/eclipse-workspace/blink/build" -P C:/Users/peter/esp-idf/components/esptool_py/run_esptool.cmake"
esptool.py --chip esp32 -p COM3 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 2MB 0x8000 partition_table/partition-table.bin 0x1000 bootloader/bootloader.bin 0x10000 blink.bin
esptool.py v3.0

INSTRUMENTATION_FAILED when run android automation test from sh

I'm doing automation test for an android app. My test code is ready and good to run from android studio and manual command from android device. But when I change the command to sh, it failed with INSTRUMENTATION_FAILED. Anyone can help me how to fix it? I just don't understand, why it's working when directly run from terminal, but failed when run from sh.
Manual input comment, which is working:
am instrument -w -r -e debug false -e class com.amap.auto.androidautomation.testcases.basemap.SmokeTest com.amap.auto.androidautomation.test/android.support.test.runner.AndroidJUnitRunner
Result:
INSTRUMENTATION_STATUS: numtests=9
INSTRUMENTATION_STATUS: stream=
com.amap.auto.androidautomation.testcases.basemap.SmokeTest:
INSTRUMENTATION_STATUS: id=AndroidJUnitRunner
INSTRUMENTATION_STATUS: test=smoke01
INSTRUMENTATION_STATUS: class=com.amap.auto.androidautomation.testcases.
Run from sh:(the command is the same as manual, just put it in a sh file)
sh r.sh
Result:
INSTRUMENTATION_STATUS: id=ActivityManagerService
INSTRUMENTATION_STATUS: Error=Unable to find instrumentation info for: Component
Info{com.amap.auto.androidautomation.test/android.support.test.runner.AndroidJUn
}tRunner
INSTRUMENTATION_STATUS_CODE: -1
android.util.AndroidException: INSTRUMENTATION_FAILED: com.amap.auto.androidauto
mation.test/android.support.test.runner.AndroidJUnitRunner
at com.android.commands.am.Am.runInstrument(Am.java:1093)
at com.android.commands.am.Am.onRun(Am.java:371)
at com.android.internal.os.BaseCommand.run(BaseCommand.java:47)
at com.android.commands.am.Am.main(Am.java:100)
at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:251)
: not foundnload/r.sh[2]: exit

Studio 2.2 has an android-19 x86 system image that runs with Qemu2 and the ranchu hardware - how was it built?

I am attempting to build a 5.1 x86 Emulator "System Image" that can be used by the latest Android Emulator, which uses a much newer Qemu code base, and has fewer problems with network bridging (for example). But I've run into a real mystery, the answer to which might explain why this task is giving me so much trouble. So first, a little back-story...
Android-19 (KitKat, ~4.4) used an ancient version of Qemu as the base for its emulator. The Android team subsequently announced that they were moving to "Qemu2", a newer/better code base, and its first use would be to support arm64 emulation, using a new emulator hardware definition called "ranchu". This did ship in Lollipop (~5.x, android-20-22), and unfortunately the x86 support was in fact omitted.
But here's the mystery - when you run the 4.4/KitKat x86 system image that is in Studio 2.2/Build Tools 25.0.2 with the -verbose flag, you can see that it is using the new Qemu, as well as the "ranchu" hardware definition and kernel:
Concatenated QEMU options:
/Users/xx
xx/.android-sdk/emulator/qemu/darwin-x86_64/qemu-system-i386
-dns-server 10.11.11.11,10.11.11.14 -serial null -cpu android32
-enable-hax -smp cores=2 -m 1536 -lcd-density 320 -kernel /Users/xx
xx/.android-sdk/system-images/android-19/default/x86//kernel-ranchu
-initrd /Users/xx
xx/.android-sdk/system-images/android-19/default/x86//ramdisk.img
-object iothread,id=disk-iothread -drive
if=none,overlap-check=none,cache=unsafe,index=0,id=system,file=/Users/xx
xx/.android/avd/Nexus_10_API_19.avd/system.img.qcow2,read-only
-device
virtio-blk-pci,drive=system,iothread=disk-iothread,modern-pio-notify
-drive
if=none,overlap-check=none,cache=unsafe,index=1,id=cache,file=/Users/xx
xx/.android/avd/Nexus_10_API_19.avd/cache.img.qcow2,l2-cache-size=1048576
-device
virtio-blk-pci,drive=cache,iothread=disk-iothread,modern-pio-notify
-drive
if=none,overlap-check=none,cache=unsafe,index=2,id=userdata,file=/Users/xx
xx/.android/avd/Nexus_10_API_19.avd/userdata-qemu.img.qcow2,l2-cache-size=1048576
-device
virtio-blk-pci,drive=userdata,iothread=disk-iothread,modern-pio-notify
-drive
if=none,overlap-check=none,cache=unsafe,index=3,id=sdcard,file=/Users/xx
xx/.android/avd/Nexus_10_API_19.avd/sdcard.img.qcow2,l2-cache-size=1048576
-device
virtio-blk-pci,drive=sdcard,iothread=disk-iothread,modern-pio-notify
-netdev user,id=mynet -device virtio-net-pci,netdev=mynet -netdev
user,id=mynet2,net=10.0.3.0/24 -device virtio-net-pci,netdev=mynet2
-show-cursor -L /Users/xx xx/.android-sdk/emulator/lib/pc-bios
-soundhw hda -vga none -append 'qemu=1 androidboot.hardware=ranchu
clocksource=pit android.qemud=1 console=0 console=0
android.checkjni=1 qemu.gles=1 ndns=2' -android-hw /Users/xx
xx/.android/avd/Nexus_10_API_19.avd/hardware-qemu.ini
So my question is - how was this system image created? The facts imply that an entirely different build system put it together. The code that would create a 4.4 system.img file that supported ranchu doesn't exist in the aosp 4.4 branch! And while it does exist in the 5.1 branch, it only supports arm64. So - is there anyone out there that can explain what up here?

PPC64/Power7 emulation on x86_64

I have used CellSDK in past to emulate/debug and test code for powerpc7 architecture on x86_64 machines. Now i want to emulate test code for upcoming (Google/intel etc) PowerPC8 compiler is available, can someone tell me qemu that can emulate ppc64 on x86_64 so i can test code(scheduler) on it .

The minimum Requirement to emulate ppc kernel on Qemu is qemu binaries kenrel image and rootfs.
For arm its like this
qemu-system-arm -M versatilepb -m 128M -kernel zImage -hda rootfs.ext3 -no-reboot -show-cursor -usb -usbdevice wacom-tablet -no-reboot -serial stdio -m 256 --append "root=/dev/sda rw console=ttyAMA0,115200 console=tty mem=256M highres=off console=ttyS0"
For more details on ppc_64 have a look at
http://gmplib.org/~tege/qemu.html
here 10 and 11

You might want to use IBM SDK other than CellIDE.
https://www-304.ibm.com/webapp/set2/sas/f/lopdiags/sdklop.html
Also, if you are doing open source development, you can try to get a free access to real ppc64 machines. It works pretty well.
http://openpower.ic.unicamp.br/minicloud/