I have been running CTS tests (Android L, CTS v7) on Intel Baytrail based devices.
Host side setup is:
1.Ubuntu Linux 14.04 LTS.
2.Open JDK 1.6/1.7
While running CTS tests I face below frequent issues:
Tests get stopped after the device gets rebooted after 200 tests as per CTS tradefed framework.
I see a huge number of pseudo failures (generally not seen by other team when run at other location).
ADB does not work with super speed ports.
Here are the possible reasons for the issues you are facing:
Device Presettings should be done in accordance to Google Recommendations:
https://source.android.com/compatibility/cts/setup
Check with the wifi connected to device is consistent during execution
Check out the display doesn't turn off during execution.
Related
I wanted to spin up an Android emulator, and always got the message The emulator process for AVD was killed
After trying to run it manually from within the command line, I got the following errors.
WHPX: Failed to get virtual processor registers, hr=c0350005
WHPX: Failed to emulate PortIO access with EmulatorReturnStatus: 64
WHPX: Failed to exec a virtual processor
This used to work on previous versions of Windows Insider, now it doesn't.
Is there anything I have to do?
It's a Windows bug that has been presented recently. There is no known solution so far.
The temporary fix is to turn off hypervisor until a Windows update is released. Windows 10 21296 has a known issue.
You can go to your windows setting --> Update & Security --> Troubleshoot --> Additional troubleshooters --> Program Compatibility Troubleshooter --> choose Android Studio, now it will open and you can start your Emulator, now it come a reboot message --> reboot it and now it should works
I'm struggling with Android emulator version 26.0.0.0. The tools are managed by the Android Studio (2.3.1). All this running on Fedora FC25 with latest updates.
I can't seem to get the ARM emulator to have network access. Same works fine with x86/x64, but not arm (or arm64).
It looks like I ran to the end of my abilities to debug what's going on, and on where to continue digging.
On arm : no ability to resolve names, no ability to connect to the outside network. I'm running nc from adb shell to check the connectivity. On an arm emulator, I get timeout on host lookup when using host name, and no route to host when attempting to connect by IP. Browser application also can't connect. I run strace on the emulator and I don't even see attempts to connect to the DNS server.
On x86 : everything works. However I did have to add -dns-server option before it started working.
Debugging The most I did was running strace for both the emulators and examining the difference. AFAIU, there is an I/O thread that gets to make the requests, and it looks like it's not picking up the requests in arm case. Or the requests are not properly deposited. The thread seems to be OK otherwise, it iterates between polls and futex locks.
Of course, my whole point is to run ARM emulators (needed to debug certain ARM native code).
Debug outputs (I did remove multi-touch connection errors from the output):
arm
x86
Any pointers on where to dig, or what I may be doing wrong is greatly appreciated. I can post full trace files from running both as well.
update your Android emulator to v26.1.0, it will work fine.
I am new to Appium.
I am able to run protractor e2e tests, on 1 Android device connected to MAc using USB cable. Appium server started as shown below.
appium -a 127.0.0.1 -U DEVICEID
however this does not seem to be ideal option when planning to run on multiple devices (around 20 iOS, Android devices).
Would you please advise, if its possible to run tests on Multiple Android + iOS Devices over wi-fi, by specifying device details in Protractor.conf.js.
Kindly please share your thoughts or experience on this.
Thanks in advance.
Yes, you can run same test on multiple devices. All you need to do to run Appium ports as many as you want to run on devices. Mention the UDID and port in your script and run it. For more info, read this.
I using AMD processor. I have installed everything related to eclipse perfectly. But I'm unable to start the emulator. program is hang and keep waiting for adb forever. The same issue in android studio also. Please give a solution.
I'm using a Android Studio on an HP x360, which is a nice little laptop but has a puny processor:). I spent ages getting the Intel Hax virtual machine thingy installed on my machine, as well as configuring bios (which I found AVAST blocked changes to, so had to uninstall it).
After probably hours this week (I'm new to Android) waiting for the emulator to do it's thing, start up, load program, and eat memory, I decided to plug in my phone (Moto-e).
This has made a massive improvement! Only takes a minute to compile and run now! You also have piece of mind that your app will run in the real world.
So as a newb to Android, I'd say don't bother with the emulator.... plug a real device in.
See here for setting up HAXM, if you have trouble installing, it may be antivirus etc blocking it....
Intel HAXM
All the best.
try these threads Virtualization threads
I was trying to play with several tiny operating systems in an emulator but got stuck with Contiki in QEMU. Ideally the compiled executable should be run as a kernel in QEMU. For all OS's I was playing with I used this simple command to run executables in QEMU:
qemu-system-platform -nographic -kernel compiled_executable
In the case of Contiki, QEMU freezes regardless of any target platform the executables are compiled for, even for target platform "native", which according to the documentation, is built with "x86 gcc".
I also tried ARM-based platforms with the same freezing issues. If I specify a correct CPU model (e.g. cortex-m3 for cc2538dk), I received a segmentation fault instead.
I am wondering if I was missing any steps to cause the QEMU to freeze. Does it mean that the compiled executable cannot be treated as kernels (yet), unless I provide some QEMU-specific codes to initialize QEMU as a "board" for Contiki?
The native platform is used to build a "natively" (i.e. on Linux or other OS) executable image of Contiki - an userland app, rather than an OS kernel.