Or finally fix the activities and fragment mess?
With full virtualization, the contact surface is restricted to a few low level bits in the kernel along with a few HALs/drivers that need to talk to the host for meaningful/fast I/O, like input/network/graphics, and everything else can be kept stock with no modification. This allows us to ship largely the same binaries that would go on a dedicated Android device and have it be able to run on windows/macos/linux easily, and it's how we've been able to keep up with the pace of yearly Android releases.
Edit: Oh and note that we are totally aware of and bummed out by emulator's increasing resource usage as android version bumps up, to the point we're afraid that the next one will finally be the one that really needs all resources of a modern PC; as such, we're looking into ways to minimize the cpu/ram/disk footprint of the system images, keeping only the bits that are actually needed for testing apps (with Google Play Services, and being better at maintaining/promoting more stock AOSP images in the case where GMS isn't needed)
So this is basically the simulator situation, but with easier management of which libraries the guest userspace can dlopen and files to read()/write().
It's much like current Android-on-ChromeOS capabilities where containers are used to isolate where the "guest" userspace libraries are stored, so that it's not necessary to interop well with things like the host version of libc for example.
However, the problems come when considering the interface to the host kernel and hardware. Here are just two of the showstoppers:
1. Android expects to run on a particular range of kernel versions and configs each release. Fidelity is sacrificed to run with a wide range of Linux host kernel configurations. It's also easy for components on the host system such as SELinux to interfere with guest operation (and Android itself expects to use its own version of SELinux...so which one wins in the end?).
2. Further customization in the guest userspace needs to be made to account for needing to interop with a regular Linux system; e.g., input/network/display will be much more code that touches various parts of guest userspace and potentially hurts fidelity versus the VM abstraction where they are fake hardware and no customization of guest userspace is needed.
There are also isolation issues that involve more delicate dances, such as how to prevent runaway resource usage in the container from hogging the whole system (VMs merely waste the #vcpus + RAM dedicated to them; while that can be a lot compared to the host, it's explicitly controllable).
These problems sound less serious on the surface versus porting the Android framework directly to the host OS, but in the end it's basically the same level of essential complexity; containers just let you remove the incidental complexity of guest userspace libraries leaking into your /usr/lib and interop w/ your filesyste.
And once we try to run on non-Linux systems we're back at square one needing to port all userspace code to the host OS (Unless you're running Docker on macOS/Windows in which case you'd be creating a VM again, sacrificing all the benefits of containers versus VMs while keeping the complex customizations).
This is probably why Microsoft is pushing WSL2, ChromeOS skipped Android 10 support and is looking into ARCVM, and anbox is still running Android 7.1.1 (w/ plans to update but skipping releases in the meantime).
And yeah, as of Android Studio 3.x (was waiting for the official 4.0 release), it was trying to nudge towards using the Google Play Services images pretty hard.
But this is pretty much what Android Emulator is - a fullish VM on a Linux base.
On all my PCs it is faster to build to device than having to deal with the emulator competing with Android Studio for hardware resources.
Not everyone has Google level budgets for hardware.
Neither of which required anything resembling a latest generation hardware. Try it again before you pretend your experiences years ago are still relevant.
I tell you why, you have forgotten to mention that "Extended Page Tables (EPT), and Unrestricted Guest (UG) features" are also required.
> Not everyone has Google level budgets for hardware.
Given that my current one runs Windows 10 64bit Pro, Visual Studio 2019, OpenJDK 14, clang 10 and Eclipse 2020‑03 just fine, I am not upgrading a perfectly working computer just to make Android emulator, or are you offering to get me one?
Specially since it was a Google's decision to drop support for its capabilities around Android 7 emulator release.
You can get a system that will run the emulator with great performance for less than $50 on Ebay. There's no possible way to describe or classify this as requiring "Google level budgets for hardware." If you can't afford to upgrade that sucks, but you also can't at all make a reasonable complaint about performance when insisting on using a 10+ year old system.
I have... an idea.
Unfortunately, there is only an aarch64 emulator for Android 7, which does not start on my system
What does that mean? The x86 system image can run arm code? I will try that (might get confusing if there is an arm and x86 lib in the apk).
I have been using the image without google apis to save space, because my sdd is almost full
Does it reject invalid arm? I wrote my app in Pascal, and the FreePascal compiler often generates invalid assembly. Especially because I need to use the nightly build, because the last stable release does not support aarch64
(Also AFAIK illegal instructions are still validated and trapped as SIGILL or SIGSEGV)
hw.audioInput=no hw.audioOutput=no
to every AVD I create. Otherwise, the Android Emulator uses 100% CPU all the time, even when it's been idle for minutes.
I'm far from the only one having the problem, see https://stackoverflow.com/questions/37063267/high-cpu-usage-...
I'm on a Macbook Air 2014, Intel i5, 8GB of RAM, 500GB SSD. Hardware acceleration, etc. all enabled.
https://drive.google.com/open?id=1sXEQcoiNpe3Lj8yeaKLasTjqlGQwy4Oi
install repo from depot_tools https://www.chromium.org/developers/how-tos/install-depot-to...
pip install absl-py
pip install urlfetch
mkdir emu
cd emu
repo init -u https://android.googlesource.com/platform/manifest -b emu-master-dev --depth=1
repo sync -qcj 4
cd external/qemu
python android/build/python/cmake.py
# run
objs/emulator -avd avdName -no-snapshot
# when it spins:
# method 1: go to activity monitor -> sample process, send over the result
# method 2: lldb
lldb
process attach --pid <pid-of-qemu-system-<arch>>
bt all #send it over
# method 3: guest process taking CPU
adb shell top$ANDROID_SDK_ROOT, if not set, should be set to the SDK location in Android Studio > Preferences > Android SDK (SDK path will show up there).
Set it in your ~/.bash_profile too so it's there next time for running the emulator from the command line.
The AVD config.ini can be found in ~/.android/avd/nameofAvd.avd/config.ini .
I have to use MacBook 13 (2019) in my current project, and it's having troubles with the emulator. Not sure if it's about the hardware or macOS inefficiencies, but I can't wait to get back to my Linux desktop where the emulator is buttery smooth, almost feels like a part of the system itself.
I don't want to upgrade the PC as I love it the way it is and it's enough for everything else. I feel like I'd like to make a simple app for my phone occasionally (just for fun and to make something in my life easier) but emulation seems impossible.
What I have resorted to is writing single-page JavaScript apps and running them in the browser so I can debug them in the host browser instead of an emulator.
Windows and Linux themselves in a VM is probably reasonably ok on your hardware because both of those OSes are built to run on non-current hardware (especially Linux; I'm running Debian buster with a current kernel on a circa 2010 single-core ARMv5 CPU with 256MB of RAM with no problems).
Android doesn't target old hardware; I wouldn't expect a current release to run all that well even on a four-year-old phone, let alone a 10+-year-old laptop with virtualization overhead.
Also the usual stuff applies: be sure you have your system's virtualization extensions enabled if it has any, use the x86 Android emulator image with hardware accel enabled, not the ARM one, etc. But that still may not be enough.
Just curious, which board is that?
i'm with you that android emulation is pretty slow, but your machine is reaching near parity with many of the devices that run the platform you're trying to emulate.
it's nearly always the case that an emulator host has to have a significant performance margin over the guest just to account for the inaccuracies/inconsistencies/hacks that are involved in mimicking a system on a dissimilar hardware platform.
EDIT: Also make sure you've enabled VT-x if your laptop has it.
An Android app I want to write is going to be a single form with some text fields and some buttons, it will have simple logic but it needs to run in background, be able to read a sensor, read/write some SQLite/CSV data and play a sound occasionally. No fancy graphics bells and whistles.
This seems like a very simple task to handle, I bet it's not going to take much RAM or CPU.
Why is it so hard to emulate?
- Galaxy S9+ (2018): 6GB
- Galaxy S10 (2019): 6 or 8 GB
- Galaxy S10+ (2019): 8 or 12 GB
- Galaxy S20 (2020): 8 or 12 GB
- Galaxy S20 Ultra (2020): 12 or 16 GB
- OnePlus 3 (2016): 6 GB
- OnePlus 8 (2020): 8 or 12 GB
- LG G7 ThinQ (2018): 4 or 6 GB
- LG Velvet (2020): 8GB
- Pixel 4 (2019): 6GB
- Xiaomi Pocophone F1 (2018): 6 or 8GB
- Huawei Mate 20 (2018): 4 or 6 or 8GB
- Sony Xperia 1 (2019): 6GB
- Moto Razr (2020): 6GB
You're trying to emulate an entire OS here. Android 10 requires a minimum of 2GB of RAM just on its own now. You have overhead for the emulation software itself on top of that, in addition to the memory needed by your computer's OS, your IDE, your browser, etc. Android Studio alone requires a minimum of 1GB and, at least in my experience, it will use that within 5 minutes of opening up.
Not to mention, even budget phones today are at least twice as fast as the CPU you're running.
You can't expect emulated software to run well on a computer that barely even meets the minimum requirements for that software. It's ludicrous.
Ok. I can see no reason to care about such though. What the heck do they need that for?
> You're trying to emulate an entire OS here.
But I emulate desktop Linuxes and Windows without problems - that's entire OSes too.
> Android 10 requires a minimum of 2GB of RAM just on its own now.
Why? What does it need this much for? Anyway, I can reserve 2GB of RAM now and I'm sure I'm not going to notice too much drop in performance.
> You can't expect emulated software to run well on a computer that barely even meets the minimum requirements for that software. It's ludicrous.
As for the app - I'm sure it can't require anything near that much. As for the OS - why does Android have to require so much more than Linux and Windows do?
BTW my actual phone (Galaxy Note 3) runs Android 9 on 3 GB RAM perfectly. I never tried 3D games but everything else is blazing fast. I've been updating it (Android 4-5-6-9) for years and never noticed a glitch.
> Why? What does it need this much for?
As a developer, that shouldn't matter to you. Only that it _does_ require that much. You can assume that your users will have 4GB of memory in almost all cases now, whether you agree with it or not. Your opinion on the _why_ is irrelevant, frankly.
If you can't provide that much to the emulator, you can't expect to run it smoothly. There is no magic solution to this. These things require resources that your computer does not have. If you want it to run better (or even at all), get better hardware. That's all there is to it.
Core2Duo was released over 13 years ago, and discontinued over 7 years ago.
Time to think about upgrading before complaining about performance issues. Especially for emulation.
Also I don't believe that PC isn't painful to use for everything else. I had a core2duo a while back and it was slowish back then.
Then why is desktop Linux and Windows emulation not nearly as slow? Windows 7+ emulation is slightly slow, especially running VisualStudio on an emulated Windows7 is painfully slow (while perfectly swift on non-emulated) but still usable if you have enough patience (Android emulation is absolutely unusable). Emulated (VirtualBox on a Linux host) Windows XP runs even faster than on bare metal.
> Also I don't believe that PC isn't painful to use for everything else. I had a core2duo a while back and it was slowish back then.
You probably did something wrong. It's not just painless, it's perfectly swift (both with the latest KDE Plasma and with Windows 7). I have a modern PC at the office (late pre-Ryzen AMD, 8GB RAM, Win10) and its perceived performance is the same. It even feels more slow (less responsive) than the Core2Duo occasionally but I blame that to Windows10.
Of course I only mean basic tasks like browsing the web, watching videos (1080p or less), juggling files and writing code (VisualStudio, IntelliJ) for small projects. Obviously any modern CPU will beat Core2Duo in video transcoding, modern games etc.
VT-D makes your Core2Duo better able to emulate Windows or Linux in hardware, but not Android.
Like I said, I don't believe that a Core2Duo isn't slow for everything you mentioned. I had one at home. I wasn't doing anything wrong - I know how fast it isn't - we had hundreds at my work. Have you noticed that other commenters are saying the same thing about Core2Duo speed as me? You must have more patience to wait for your PC than myself and the other commenters.
The reason I replaced my Core2Duo was because it was slow, and I replaced it around 8 years ago!
(Regardless, reimplementing Windows APIs without documentation and writing a simulator for a phone OS are two completely different endeavors.)
An Android app is a Java app using a set of special APIs. Why can't it run on a host JVM given some libraries implementing the same APIs? I'm not interested in the NDK.
That's a hideously huge API surface to double-implement - with a new and unique set of bugs reducing it's usefulness in CI builds - for slightly improved performance in a relatively niche dev edge case (!ndk android dev without android hardware.) You'd also need to skip conversion to DEX format (or convert back) to run on a standard JVM.
But your suggestion isn't technically impossible. You could (re)implement the subset of APIs your application happens to use yourself, if you really wanted to go down that route - which by virtue of being a much smaller subset of the APIs than the entire Android Java API surface, wouldn't even be practically impossible.
The only exception to that is libsystem_{pthread,kernel,platform} because those form the kernel's ABI boundary. Libraries like libc, libdispatch, et al are the iOS build and use the iOS ABI.
If your desktop can't replicate the performance of your phone, it's misconfigured or seriously underspecced.
During typing this comment I nearly lost my mind because my macbook shift key is playing up and other keys are doing key repeats. I think I might go insane, stupid butterfly design
And what issues did you have with activities and fragments?
Oh, on those. Compared to iOS and ViewControllers, they just isn't a comparison. Starting them? Oh, can I do new Activity()? Nope, use this Intent thing. Rotation? Good luck! Passing data around? I have to use a bundle? Why can't I set a variable inside, like any other object?
Just to start. :)
You can just set variables like normal Java just fine. The bundle thing is only necessary to preserve data across process deaths.
Your best bet to pass data around is to... not pass it but rather use a sophisticated DI setup where you can set up shared objects that live in a certain scope. Of course, you can add parameters to a bundle with some boilerplate, but that's not a great idea if the serialization overhead hurts you.
That said - I'd highly recommend checking out the Navigation components that are a part of Jetpack. They make standard navigation patterns, including deep linking, a complete breeze.
It's just frustrating that 10 years later, we still have nothing that is remotely capable of the things an iOS ViewController can do.
It would surely be nice to have the option but a good emulator is needed.