I want to test TrustZone feature in mainline QEMU and let QEMU run android image. The TrustZone feature is not in qemu-ranchu which is emulator of android built on top of old version qemu. Qemu-ranchu does not include TrustZone feature. So I have to use plain qemu to run trustzone feature on android.
I already compiled the AOSP with arm64 option and I have following image file: ramdisk.img, system.img, cache.img, userdata.img. I want to use qemu-system-aarch64 run these AOSP images.
Could anyone provide some guide line what command should I use to let qemu run these android images? Thanks in advance.
Although I don't know what "TrustZone" is, I think you are confused - "ranchu" is a hardware definition that the new Emulator can use, and it, in turn is based on a much newer Qemu code base.
In any case, you can see exactly what options are being used to run qemu by the Android Emulator (which "wraps" qemu) by starting it from the command line with the -verbose flag, for example:
~/.android-sdk/tools/emulator -avd Nexus_10_API_19 -verbose
I've had some luck running qemu directly by copying those options, and by experimenting with the values that are printed out by the Emulator "wrapper" code.
BTW, you will first need to use Studio's "AVD Manager" to make an avd to use in that command. More information about the command line use of the Emulator can be found here:
Android Emulator Command Line
Good luck!
Related
I built AOSP 5.1.0_r5 (LMY47O) with no modifications done to the source code. The build process ends with "success" and I get bunch of *.img files in out/target/product/deb. Sadly, executing emulator -verbose produces the generic emulator window with an empty screen and following output in the console. I see nothing that would explain the black screen. (I am looking at the black screen for tens of minutes, hence I doubt it is "merely very slow.")
My environment is Ubuntu 16.04 running in VirtualBox under Windows 7, no IDE involved.
Just an assumption. You have a line in your output: Failed to create Context 0x3005
Could not initialize emulated framebufferemulator: Can't start OpenGLES renderer? It seems that this is the cause of the problem. Could you please install the following libraries sudo apt-get install mesa-utils-extra and run your emualator once again?
P.S. What is the target deb? Try to build the AOSP using a recommended target, e.g., aosp_arm-eng.
I am trying to decrease the ridiculous CPU usage of my Android emulator.
Thanks to this answer I found out that the CPU usage can be greatly decreased by disabling audio.
Solutions
I found out there are three ways to run the emulator without audio.
As a command line flag:
$ emulator -avd <name> -noaudio
By editing ~/.android/<name>.avd/config.ini and replacing this line:
hw.audioInput=yes
with these two:
hw.audioInput=no
hw.audioOutput=no
Instead of using the graphical AVD manager, use the following command to create an emulator:
$ android create avd -n <name> -t <target>
Cons
All of these methods have downsides though.
Requires to pass the -noaudio flag each time. This means it can't be run from AVD manager.
config.ini is reset each time an edit is made using AVD manager.
Requires to explicitly set every property of the device instead of just being able to use a preset configuration.
Attempted (failed) solution
I decided it might help to just clone an existing device and disable the audio there.
However¸ this just created ~/.android/devices.xml and I couldn't fine any reference how to disable audio by default nor any ini files containing hardware definitions.
Question
Is it possible to create a predefined hardware configuration that has sound disabled by default? If so, how?
I downloaded a third-party ROM, and I want to run it on the emulator first before flash it into the phone. Here is the contents of cm-11-20140911-NIGHTLY-p3110.zip:
1. boot.img
2. file_contexts
3. META-INF/
4. recovery/
5. system/
I unpacked boot.img using the script unpack-bootimg.pl and get boot.img-kernel, and boot.img-ramdisk.cpio.gz. Then I repacked the system using the make_ext4fs and got system.img.
I created an AVD and execute:
emulator -system ~/cm11/system_new.img -ramdisk ~/cm11/boot.img-ramdisk.cpio.gz -kernel ~/cm11/boot.img-kernel -avd and442
but all I got is nothing, the emulator screen is just black. There is no log message from adb -s emulator-5554.
Now I am confused:
can the third-party ROM be tested by the emulator?
Am I doing the right way?
Yeah, why not.
We can flash a third-party ROM on Android AVD. But first you must know the following things:
1. The Android Emulator is itself a device, like your Moto G or Xperia
2. Every ROM is device-specific (supports a device-specific Kernel)
(on many sites/blogs you got information like you have to replace system.img file from .android\avd\avdname.avd, but it is technically incorrect, because you also require ramdisk.img.)
To do this, you need to create your own AOSP repository by downloading the particular repository and have to build your own .img files)
You can do it in two ways:
replace files system.img and ramdisk.img from location .android\avd\avdname.avd
Build your own AOSP. Before... make in "lunch" select target as: Emulator (like: genericX86), i.e., generate all emulator specific .img files
I have tried many things. It's a bit critical, but interesting. The following links may help you:
To run your cooked ROM on Emulator (link down. Try this, from archive.org).
To Create AOSP Project
I'm using Fedora 19 64 bit (GNOME 3) for Android development.
locate libGL gives me:
/home/ericnguyen/adt/sdk/tools/lib/libGLES_CM_translator.so
/home/ericnguyen/adt/sdk/tools/lib/libGLES_V2_translator.so
/usr/lib/libGL.so.1
/usr/lib/libGL.so.1.2.0
/usr/lib64/libGL.so.1
/usr/lib64/libGL.so.1.2.0
/usr/lib64/libGLU.so.1
/usr/lib64/libGLU.so.1.3.1
/usr/share/doc/mesa-libGL-9.2
/usr/share/doc/mesa-libGL-9.2/COPYING
Right now I'm not able to start the emulator using my computer's GPU
Failed to load libGL.so
error libGL.so: cannot open shared object file: No such file or directory
So, I'm trying to find the appropriate libGL.so file to do as this.
Also, when I:
yum install mesa-libGL.x86_64
I got:
Package mesa-libGL-9.2-0.14.20130723.fc19.x86_64 already installed and latest version
Nothing to do
Notes:
I'm able to run the emulator without the GPU just fine.
My graphics card is AMD ATI Radeon HD 5000 series. I don't think I have installed any driver for it yet. I did yum search radeon and found xorg-x11-drv-ati.x86_64 but I'm not sure whether that's the correct driver - I have found people running into startup problem trying to install graphic card drivers (my own experience with Windows) so I'm a little uncertain right now.
I am also aware that one will need to install proprietary software from AMD/ ATI to to be able to use the graphics card.
The emulator is a 32-bit app. You need to install the equivalent 32-bit libraries. From the Fedora wiki HOWTO Setup Android Development the recommended libraries are:
glibc.i686 glibc-devel.i686
libstdc++.i686 zlib-devel.i686
ncurses-devel.i686 libX11-devel.i686
libXrender.i686 libXrandr.i686
If you can run the emulator without GPU support I will assume you have all of those.
For mesa-libGL your yum command is attempting to install the 64-bit version of the library, so try this instead:
yum install mesa-libGL.i686
EDIT (after Question update):
Yes install the The xorg-x11-drv-ati driver if it isn't already. This is the opensource driver and if it doesn't work you should just drop back to whatever you are running now.
I have an Nvidia card, but have had this running with my previous ATI card. I assume something has changed with the emulator since I set mine up a while ago as it seems to be running with the 64bit libraries:
$ pldd 9989
...
...
./lib/lib64OpenglRender.so
/opt/android-sdk-linux/tools/./lib/../lib/lib64EGL_translator.so
/usr/lib64/nvidia-304xx/libGL.so.1
/usr/lib64/nvidia-304xx/tls/libnvidia-tls.so.304.88
/usr/lib64/nvidia-304xx/libnvidia-glcore.so.304.88
/opt/android-sdk-linux/tools/./lib/../lib/lib64GLES_CM_translator.so
/opt/android-sdk-linux/tools/./lib/../lib/lib64GLES_V2_translator.so
/lib64/libGL.so
/lib64/libglapi.so.0
/lib64/libXdamage.so.1
/lib64/libX11-xcb.so.1
/lib64/libxcb-glx.so.0
/lib64/libxcb-dri2.so.0
...
...
..
....
(9989 being the process id of the running emulator.)
So installing the drivers you have already mentioned should be enough.
You can test if the emulator is using them with just the emulator and the JellyBean Easter Egg.
emulator -avd <your_avd_name> -gpu on
should give you noticeably better performance than
emulator -avd <your_avd_name> -gpu off
A little extra info:
You can install the proprietary driver xorg-x11-drv-catalyst, if you want to try it, from RPM Fussion and will find it in the non-free repo there.
If you don't have them already have RPM Fussion repos on your system (detailed instructions on there site.) I strongly recommend them. They are well supported and will give you less headaches than using some of Fedora equivalents (they return mp3 support to packages, for example.)
You say you are new to Linux (or maybe you mean playing with drivers on Linux) either way an FYI: You don't need to include the target platform when install packages (i.e. the .x86_64 .i686) Yum will sort that out for you unless you need libraries for an architecture other than the one you are running.
I'm extending a custom Android kernel fork that originated as a 2.2
Froyo kernel. The build process itself is no problem; just type "make"
and its done. But I'm not sure of what I need to do to make the new
kernel known to other tools in the Android SDK; particularly
the emulator, adb, and the Eclipse debugger.
I've tried various things such as running the emulator with -system and
-userdata arguments on the command line, and these appear to work,
although I hit sporatic problems that leave me unsure. A common problem
I've seen is that sometimes apps "hang", displaying their UI but
refusing to go away even when the home or menu buttons are clicked. I've
tried turning off caching. But the real problem here is that I don't
have a good mental model of how kernel builds should be conveyed to
the SDK.
Should I be copying the build results (.img files) to
~/.android/ perhaps? Or to somewhere in the
SDK folder?
A working recipe would be nice, but better yet would be a
understanding of how the kernel build and SDK tools work together.
For example http://source.android.com/source/using-eclipse.html is
great for recipes but I still don't see how adb and emulator know
where to load .img files from.
When you've built android image the android webpage recommends to run it with emulator command. But you can run the built image in this way because android envsetup command has specified some paths before. For instance, to test my built image I run command:
out/host/linux-x86/bin/emulator -sysdir out/target/product/generic/ -system out/target/product/generic/system.img -ramdisk out/target/product/generic/ramdisk.img -data out/target/product/generic/userdata.img -kernel prebuilt/android-arm/kernel/kernel-qemu -sdcard sdcard.img -skindir sdk/emulator/skins -skin WVGA800 -scale 0.7 -memory 512 -partition-size 1024
So as you can see I specify all the images and all the paths explicitly. This is command to run image in emulator. Out folder is created during the build in your android source root folder.
P.S. Kernel usually refers to Linux kernel of Android. In your case, I think you have changed Android framework.
I've composed a full answer based on the invaluable clues Yury provided. The solution was to add these settings to my .bashrc. The tools (emulator, adb, ddms) in eclipse use these settings to pick up stuff from ANDROID_TARGET_OUT instead of getting them from the prebuilt copies inside the SDK. The CACHE stuff is the standard recommendation.
# Android SDK Build settings
export ANDROID_HOME="/Volumes/DroidImg/android-sdk-macosx"
export ANDROID_SDK_ROOT="$ANDROID_HOME"
export ANDROID_SDK_BASE="$ANDROID_HOME"
export ANDROID_SDK_HOME="$ANDROID_HOME"
export ANDROID_TARGET_OUT="/Volumes/DroidImg/Droid-Kernel/out/target/product/generic"
export USE_CCACHE=1
export CCACHE_DIR="/Volumes/DroidImg/CCACHE_DIR"
ulimit -S -n 1024
Finally, copy the .classpath provided with the SDK as documented on the wiki into the root of the kernel distribution, and "import existing files" into Eclipse. All Java components should now open and build properly in the package explorer. Very handy for exploring but don't forget you have to use ordinary make to build this stuff for real.
/Volumes/DroidImg is a case-preserving disk image I made for MAC-OS work; change this part of the path to suit.