Which QEMU/KVM command line would run mini_emulator (or other) builds ?

[julien....@gmail.com]

Hello everybody,

Does anybody here know the correct KVM command to run one of the following builds (few lines below) ?

I'm really stuck and I definitely need some help - also I'm pretty sure that it's just a matter of typing a command with the correct parameters into "append" (kernel parameters) and others things. But I didn't find the good ones.

I'm struggling to run Android with QEMU/KVM, which is a little bit different compared to the official "emulator" command.

I'm doing this, because I'm trying to learn how to run Android on generic/upstream kernel supported platforms (like Intel based laptop, or just QEMU/KVM).

I've tried a lot of the available standard "lunch" choices from android-9.0.0_r35 branch, but it seems that only aosp_XXXX-eng are running out of the box with the emulator, but not with KVM/QEMU.

I also captured what are the "QEMU" parameters used by the Emulator but lot of them aren't recognized by the standard QEMU/KVM version, and so it doesn't work.

mini_emulator doesn't work with "emulator" but seems to go further than the others once started in KVM (but it freezes really quickly)

• aosp_arm-eng
• aosp_arm64-eng
• aosp_mips-eng
• aosp_mips64-eng
• aosp_x86-eng
• aosp_x86_64-eng
• aosp_car_arm-userdebug
• aosp_car_arm64-userdebug
• aosp_car_x86-userdebug
• aosp_car_x86_64-userdebug
• mini_emulator_arm64-userdebug
• m_e_arm-userdebug
• m_e_mips64-eng
• m_e_mips-userdebug
• mini_emulator_x86_64-userdebug
• mini_emulator_x86-userdebug
• uml-userdebug
• aosp_crosshatch-userdebug
• aosp_blueline-userdebug
• aosp_cf_x86_auto-userdebug
• aosp_cf_x86_phone-userdebug
• aosp_cf_x86_tablet-userdebug
• aosp_cf_x86_tablet_3g-userdebug
• aosp_cf_x86_tv-userdebug
• aosp_cf_x86_wear-userdebug
• aosp_cf_x86_64_auto-userdebug
• aosp_cf_x86_64_phone-userdebug
• aosp_cf_x86_64_tablet-userdebug
• aosp_cf_x86_64_tablet_3g-userdebug
• aosp_cf_x86_64_tv-userdebug
• aosp_cf_x86_64_wear-userdebug
• cf_x86_auto-userdebug
• cf_x86_phone-userdebug
• cf_x86_tablet-userdebug
• cf_x86_tablet_3g-userdebug
• cf_x86_tv-userdebug
• cf_x86_wear-userdebug
• cf_x86_64_phone-userdebug
• cf_x86_64_tablet-userdebug
• cf_x86_64_tablet_3g-userdebug
• cf_x86_64_tv-userdebug
• cf_x86_64_wear-userdebug
• aosp_marlin-userdebug
• aosp_marlin_svelte-userdebug
• aosp_sailfish-userdebug
• aosp_walleye-userdebug
• aosp_walleye_test-userdebug
• aosp_taimen-userdebug
• hikey-userdebug
• hikey64_only-userdebug
• hikey960-userdebug

Thank you in advance

Julien ROBIN

[Joerg Pleumann]

Hi,

unfortunately I cannot help you. But I have similar problems with the emulator alone. I want to use it to be able to create customized Android 9.x images including Google apps (we’re partner) before we have access to the real hardware for a project. It took me a while to find out that only the aosp_* lunches would support the emulator at all (some others did, occasionally, but most likely because the emulator had already been built, but normally the *-qemu.img files were missing, so it would not boot at all). I also have some sort of freezing, maybe the same that you see. Sometimes the emulator works fine for a while, sometimes it freezes immediately after boot, and each input event takes a minute to process. I have a pretty powerful machine, so that can’t be the root cause, and I already tried raising the RAM available to the emulator.

The emulator in Android studio works fine, on the other hand. So it is possible. But maybe some tweaks to the build are necessary.

Maybe someone from Google can point us into the right direction.

Best regards

Joerg

--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
android-buildi...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en

---
You received this message because you are subscribed to the Google Groups "Android Building" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-buildi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Julien ROBIN]

Hi Joerg,

Thanks for your feedback. Still stuck and looking for information, I recently found a complete book about taking as exemple AOSP and making it run on Virtual Box : Android System Programming by Roger Ye
It's about Android 7.1.1 but as this version is still available at https://android.googlesource.com/ I guess it's interesting for this case, so I'm digging into it and facing all the complicated things that I would have loved not care about - but being stuck I have no choice.

I hope answers will appear from it. If so I keep you informed here

[Julien ROBIN]

I got android-7.1.1_r58_mini_emulator_x86-userdebug working with the emulator, but in order to do so, I have to get the emulator using kernel-qemu (3.4) instead of kernel-ranchu (3.10), and I guess it was using the old "goldfish" based emulation mode. Technically, I had to do the followings :

• Created an AVD (I called it 711G_32) using AVD Manager, and System Image "x86-25_r15.zip" : x86 Images, Nougat API Level 25 x86, Android 7.1.1 (Google APIs)
  
• Deleted all that was into /home/user/.android/avd/711G_32.avd/ folder, apart from config.ini (the only single file that is necessary - and no need to change it ! This waaaaaay more simple in that way to drive test and look after parameters)
• Deleted "kernel-ranchu" file so it only remains "kernel-qemu" file. This kernel file is the same one you get when you build "mini_emulator_x86-userdebug" on android-7.1.1_r58 branch (according to size and sha1sum)
  
• running "emulator @711G_32" gave me the build starting fine. I guess it was using the old "goldfish" emulator by not being able to run the more modern "ranchu" emulator.
  
• From here, I guess that once the build is finished, when you are still in the terminal, typing "emulator -engine classic" could make the mini_emulator build running fine, but it still should be tested, with others versions (x86_64, and android 8, 9 10...)
  

For android-7.1.1_r58_aosp_x86-eng and android-7.1.1_r58_aosp_x86_64-eng it's easier : the kernel contained into x86-25_r15.zip and x86_64-25_r15.zip is fine (it's a chance because the output folder of those manual aosp builds doesn't contain any kernel). Just replacing 3 files (ramdisk, system, and userdata) is fine. Then, running "emulator @711G_32" (or 711_64) made those build working as well as when you type "emulator" after the build just finished.

For Android 9.0.0, I have some test to do :

• By the almost same approach, I successfully ran the Android 9.0.0_r34_aosp_x86_64-eng build on the emulator. I replaced the system.img and vendor.img by the "system-qemu.img" and "vendor-qemu.img" files, "userdata.img", "ramdisk.img"; "kernel-ranchu" (didn't check if it was the same), "encryption-key". I also had to delete /home/user/Android/Sdk/system-images/android-28/google_apis_playstore/x86_64/VerifiedBootParams.textproto because this file contained "dm_things" parameters that weren't working with the aosp build, and a just working with x86_64-28_r08.zip. Then it was working the same way that when you type "emulator" once the build just finished.

• Developper Settings, crashing "Settings" app as soon as you go into it :
  

• I tried to use differents kernels (android 4.19 with different configurations) but they don't work, only "kernel-ranchu" does (based on Linux 4.4) even when using system/vendor.img instead of system-qemu/vendor-qemu.img (same problem that I had when using KVM commands manually).
  

Since I'm running emulator with "-verbose -show-kernel" parameters I hope the parameters information here will help me in my quest now that I saw more things working and how I got it working.
Also, being able to simplify files about AVD devices (Deleting everything appart from config.ini is fine) will probably help me to see things more clearly, because I was very lost in all this unnecessary and frustrating complexity with almost no solution available anywhere in case something goes wrong... (namely, almost everything).

Hope this kind of information could help someone Googling for help some day ! I still have a lot of things to be done... but at least, I don't feel completely stuck anymore.

Have a nice day
Julien ROBIN