12 ms·

Did they build a real simulator yet, like iOS? Note, not an emulator, which does hardware stuff. A simulator, so we don't have to use up our entire machine to r

Did they build a real simulator yet, like iOS? Note, not an emulator, which does hardware stuff. A simulator, so we don't have to use up our entire machine to run another operating system just to run a java app. Or finally fix the activities and fragment mess?

oakesm9 6y ago
That works for iOS because it shares so much with macOS. It wouldn't work for Android as it doesn't share much with the OS.
- e12e 6y ago
  This is probably why wine doesn't exist, too. /s ;)
  - kelnos 6y ago
    Yes, and wine has been under development for 27 years and, despite its achievements, still can't run all Windows apps. (Regardless, reimplementing Windows APIs without documentation and writing a simulator for a phone OS are two completely different endeavors.)
vbezhenar 6y ago
I think that emulator is vastly superior option as it uses real Android running exactly the same code as your phone. I never had any issues with performance (with hardware acceleration). May be on extremely weak laptops it might cause issues, but Android Studio probably will be unusable there at all.
- benibela 6y ago
  I also need an emulator, because I have native binaries Unfortunately, there is only an aarch64 emulator for Android 7, which does not start on my system
  - heavyset_go 6y ago
    Anbox with libhoudini might work for you.
  - lfy_google 6y ago
    Hi, Android 9 and 11 Google APIs/Play system images should have userspace ARM translation available (with ARM64 translation available in Android 11).
    - benibela 6y ago
      > userspace ARM translation 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
      - lfy_google 6y ago
        Yes, the x86 system image can run ARM code. Note that the speed will be much faster than running a full ARM emulated system image because only the guest userspace bits need to be translated from ARM to x86. System calls are still marshalled to x86 calls, so memory accesses are many many times faster because (there's no need to drop into emulating the MMU). (Also AFAIK illegal instructions are still validated and trapped as SIGILL or SIGSEGV)
- clumsysmurf 6y ago
  A word of caution, a few times I've gone to bed with Android Studio and the emulator up; and woken up with my machine's fans running full speed and the thing about to melt down; the emulator can do funky things like take 600% of your cpu for no apparent reason after sitting there idle for hours.
  - lfy_google 6y ago
    Hi, what host OS are you running? I'd like to be able to send over a build with symbols so we can profile it (or on macos use the process sampler). Let's also try `adb shell top` next time this happens; we found that when networking state changes, sometimes, the virtual radio gets in a bad state and starts spinning.
    - kaixi 6y ago
      I need to add 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-with-android-emulator-qemu-system-i386-exe 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.
      - lfy_google 6y ago
        Interesting, sounds like a live loop in some audio thread somewhere. What's your audio setup and AVD config.ini? I might be able to reproduce on my Mac.
      - lfy_google 6y ago
        And here's the promised emulator build (from aemubins gmail account that we use to distribute debug binaries like this): https://drive.google.com/open?id=1sXEQcoiNpe3Lj8yeaKLasTjqlGQwy4Oi If you still don't get symbols from that it should be possible to build the emulator itself on macos: install repo from depot_tools https://www.chromium.org/developers/how-tos/install-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 Debugging: # 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
- distances 6y ago
  > I never had any issues with performance (with hardware acceleration). May be on extremely weak laptops it might cause issues, but Android Studio probably will be unusable there at all. 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.
  - dahfizz 6y ago
    Do you know if you have KVM set up? Or whatever the macos equivalent is? The difference in emulating in software vs hardware is massive.
- qwerty456127 6y ago
  Android emulation (I've tried both the bundled emulator and VirtualBox+RemixOS) is the most insanely slow piece of software I've ever seen in my life. It feels like if I were running Windows10 on an original 80386. My laptop is Core2Duo with 4GB RAM, IntelliJ IDEs and everything work great (especially after I've upgraded my HDD to an SSD), desktop and server OSes work great in VirtualBox but Android feels like playing chess via mail. Why does it have to be heavier than desktop Linux&Java? 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.
  - fomine3 6y ago
    Core2Duo laptop for Android dev is almost same thing like using 80386.
    - qwerty456127 6y ago
      Why does Android dev has to be this much heavier than any other task? I'm ok doing .Net, Scala and Python dev (always using the most powerful IDEs), some lo-fi machine learning, running Windows and Linux and heavy Windows apps in VirtualBox, but Android - can't emulate. 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.
      - RussianCow 6y ago
        How are you doing all of those things with only 4GB of memory? My wife's old laptop had 3GB, and with about 10 Chrome tabs open, the computer would start swapping and quickly grind to a halt—with no other programs running in the foreground. I just checked memory usage on my own machine and Firefox alone is using over 3GB for me, and IntelliJ another 4GB. Granted, I know many programs tend to use more memory if it's available (for caching, etc), and I also hardly ever restart my machine, but still... Running a full dev environment with 4GB doesn't seem like it should be possible, so I'm curious how yours is so functional.
surfmike 6y ago
I think their preferred route is to continue to make the emulator better instead.
monocasa 6y ago
Anbox is pretty much what you're asking for (Android running within a container), but as others have said, the emulator is very good. And what issues did you have with activities and fragments?
- matchbok 6y ago
  Hm, I'll have to try that out! 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. :)
  - kllrnohj 6y ago
    > Passing data around? I have to use a bundle? Why can't I set a variable inside, like any other object? You can just set variables like normal Java just fine. The bundle thing is only necessary to preserve data across process deaths.
    - lubonay 6y ago
      How do you set those variables? Do you keep a reference to your activity or fragment inside another screen? Do you clean up that reference on configuration change, or let it leak and/or cause crashes? 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.
      - kllrnohj 6y ago
        Neither the ViewModel library nor Activity#onRetainNonConfigurationInstance() is what I'd call a "sophisticated DI setup"
heavyset_go 6y ago
You can run Android in a container at native speed. You can also use containerized Android with binfmt_misc and libhoudini to run foreign binaries without having to run the entire Android OS in an emulator.
- radarsat1 6y ago
  I was wondering about that, is it possible to have an Android container on Linux that can be used from Android Studio for testing? Any info on this?
  - heavyset_go 6y ago
    No experience in that department, sorry.
robertoandred 6y ago
I wish. The Android emulator is so slow as to be almost unusable. The iOS simulator is fine.
- heavyset_go 6y ago
  iOS simulator can leverage the host's macOS libraries and kernel. Android doesn't share anything at all with Windows or macOS, and shares only the kernel at best with Linux. The best you can hope for is running Android in a container on a host Linux system, or via WSL. Unless you can get containers running natively on macOS, or run a Linux kernel a la WSL, there will need to be a layer of emulation to run Android.
  - Kipters 6y ago
    I find it a bit ironic that WSL was born for supporting Android apps on Windows (Mobile)
  - qwerty456127 6y ago
    > Android doesn't share anything a 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.
    - MaulingMonkey 6y ago
      > Why can't it run on a host JVM given some libraries implementing the same APIs? 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.
V-2 6y ago
Activities and Fragments, whatever one finds to be the problem with them, are an SDK thing, not an IDE thing.
lfy_google 6y ago
I'm on the emulator team; we've considered this route before, but the hard part about maintaining a simulator is that the contact surface with the host OS is much larger, making it so that we would essentially have to port the current year's version of Android, with all java/C userspace APIs, to all wanted host OSes. This would require much greater resources dedicated to this porting than we're able to handle, and/or we'd need to make the hard choice of only maintaining certain Android versions and skipping certain ones completely. It would also be very difficult to maintain fidelity. 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)
- CameronNemo 6y ago
  Have you considered https://anbox.io https://anbox.io ?
  - lfy_google 6y ago
    Thanks, I've read about this before but just went over it again in more detail yesterday with a fresh look. 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).
krschultz 6y ago
The activities / fragment portion of the SDK is not owned by the team that builds Android Studio and the broader toolchain.
halfjew22 6y ago
I only see one reply remotely regarding Activites and Fragments and it's just asking what problems you had. It should be pretty obvious to anyone that's tinkered with Android that the whole battle between which to choose is ridiculous. 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.
- matchbok 6y ago
  Oh, my team has tried the new stuff. It's terrible. Especially with the viewmodel stuff. Hidden bugs, no documentation, constant API changes. Hell, you couldn't scope a viewmodel to a nav graph until recently, which defeats the entire purpose of the whole thing. It's just frustrating that 10 years later, we still have nothing that is remotely capable of the things an iOS ViewController can do.
on_and_off 6y ago
emulator vs simulator just offer different drawbacks. It would surely be nice to have the option but a good emulator is needed.

oakesm9 6y ago

That works for iOS because it shares so much with macOS. It wouldn't work for Android as it doesn't share much with the OS.

e12e 6y ago
This is probably why wine doesn't exist, too. /s ;)
- kelnos 6y ago
  Yes, and wine has been under development for 27 years and, despite its achievements, still can't run all Windows apps. (Regardless, reimplementing Windows APIs without documentation and writing a simulator for a phone OS are two completely different endeavors.)

vbezhenar 6y ago

I think that emulator is vastly superior option as it uses real Android running exactly the same code as your phone. I never had any issues with performance (with hardware acceleration). May be on extremely weak laptops it might cause issues, but Android Studio probably will be unusable there at all.

benibela 6y ago
I also need an emulator, because I have native binaries Unfortunately, there is only an aarch64 emulator for Android 7, which does not start on my system
- heavyset_go 6y ago
  Anbox with libhoudini might work for you.
- lfy_google 6y ago
  Hi, Android 9 and 11 Google APIs/Play system images should have userspace ARM translation available (with ARM64 translation available in Android 11).
  - benibela 6y ago
    > userspace ARM translation 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
    - lfy_google 6y ago
      Yes, the x86 system image can run ARM code. Note that the speed will be much faster than running a full ARM emulated system image because only the guest userspace bits need to be translated from ARM to x86. System calls are still marshalled to x86 calls, so memory accesses are many many times faster because (there's no need to drop into emulating the MMU). (Also AFAIK illegal instructions are still validated and trapped as SIGILL or SIGSEGV)
clumsysmurf 6y ago
A word of caution, a few times I've gone to bed with Android Studio and the emulator up; and woken up with my machine's fans running full speed and the thing about to melt down; the emulator can do funky things like take 600% of your cpu for no apparent reason after sitting there idle for hours.
- lfy_google 6y ago
  Hi, what host OS are you running? I'd like to be able to send over a build with symbols so we can profile it (or on macos use the process sampler). Let's also try `adb shell top` next time this happens; we found that when networking state changes, sometimes, the virtual radio gets in a bad state and starts spinning.
  - kaixi 6y ago
    I need to add 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-with-android-emulator-qemu-system-i386-exe 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.
    - lfy_google 6y ago
      Interesting, sounds like a live loop in some audio thread somewhere. What's your audio setup and AVD config.ini? I might be able to reproduce on my Mac.
    - lfy_google 6y ago
      And here's the promised emulator build (from aemubins gmail account that we use to distribute debug binaries like this): https://drive.google.com/open?id=1sXEQcoiNpe3Lj8yeaKLasTjqlGQwy4Oi If you still don't get symbols from that it should be possible to build the emulator itself on macos: install repo from depot_tools https://www.chromium.org/developers/how-tos/install-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 Debugging: # 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
distances 6y ago
> I never had any issues with performance (with hardware acceleration). May be on extremely weak laptops it might cause issues, but Android Studio probably will be unusable there at all. 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.
- dahfizz 6y ago
  Do you know if you have KVM set up? Or whatever the macos equivalent is? The difference in emulating in software vs hardware is massive.
qwerty456127 6y ago
Android emulation (I've tried both the bundled emulator and VirtualBox+RemixOS) is the most insanely slow piece of software I've ever seen in my life. It feels like if I were running Windows10 on an original 80386. My laptop is Core2Duo with 4GB RAM, IntelliJ IDEs and everything work great (especially after I've upgraded my HDD to an SSD), desktop and server OSes work great in VirtualBox but Android feels like playing chess via mail. Why does it have to be heavier than desktop Linux&Java? 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.
- fomine3 6y ago
  Core2Duo laptop for Android dev is almost same thing like using 80386.
  - qwerty456127 6y ago
    Why does Android dev has to be this much heavier than any other task? I'm ok doing .Net, Scala and Python dev (always using the most powerful IDEs), some lo-fi machine learning, running Windows and Linux and heavy Windows apps in VirtualBox, but Android - can't emulate. 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.
    - RussianCow 6y ago
      How are you doing all of those things with only 4GB of memory? My wife's old laptop had 3GB, and with about 10 Chrome tabs open, the computer would start swapping and quickly grind to a halt—with no other programs running in the foreground. I just checked memory usage on my own machine and Firefox alone is using over 3GB for me, and IntelliJ another 4GB. Granted, I know many programs tend to use more memory if it's available (for caching, etc), and I also hardly ever restart my machine, but still... Running a full dev environment with 4GB doesn't seem like it should be possible, so I'm curious how yours is so functional.

surfmike 6y ago

I think their preferred route is to continue to make the emulator better instead.

monocasa 6y ago

Anbox is pretty much what you're asking for (Android running within a container), but as others have said, the emulator is very good. And what issues did you have with activities and fragments?

matchbok 6y ago
Hm, I'll have to try that out! 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. :)
- kllrnohj 6y ago
  > Passing data around? I have to use a bundle? Why can't I set a variable inside, like any other object? You can just set variables like normal Java just fine. The bundle thing is only necessary to preserve data across process deaths.
  - lubonay 6y ago
    How do you set those variables? Do you keep a reference to your activity or fragment inside another screen? Do you clean up that reference on configuration change, or let it leak and/or cause crashes? 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.
    - kllrnohj 6y ago
      Neither the ViewModel library nor Activity#onRetainNonConfigurationInstance() is what I'd call a "sophisticated DI setup"

heavyset_go 6y ago

You can run Android in a container at native speed. You can also use containerized Android with binfmt_misc and libhoudini to run foreign binaries without having to run the entire Android OS in an emulator.

radarsat1 6y ago
I was wondering about that, is it possible to have an Android container on Linux that can be used from Android Studio for testing? Any info on this?
- heavyset_go 6y ago
  No experience in that department, sorry.

robertoandred 6y ago

I wish. The Android emulator is so slow as to be almost unusable. The iOS simulator is fine.

heavyset_go 6y ago
iOS simulator can leverage the host's macOS libraries and kernel. Android doesn't share anything at all with Windows or macOS, and shares only the kernel at best with Linux. The best you can hope for is running Android in a container on a host Linux system, or via WSL. Unless you can get containers running natively on macOS, or run a Linux kernel a la WSL, there will need to be a layer of emulation to run Android.
- Kipters 6y ago
  I find it a bit ironic that WSL was born for supporting Android apps on Windows (Mobile)
- qwerty456127 6y ago
  > Android doesn't share anything a 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.
  - MaulingMonkey 6y ago
    > Why can't it run on a host JVM given some libraries implementing the same APIs? 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.

V-2 6y ago

Activities and Fragments, whatever one finds to be the problem with them, are an SDK thing, not an IDE thing.

lfy_google 6y ago

I'm on the emulator team; we've considered this route before, but the hard part about maintaining a simulator is that the contact surface with the host OS is much larger, making it so that we would essentially have to port the current year's version of Android, with all java/C userspace APIs, to all wanted host OSes. This would require much greater resources dedicated to this porting than we're able to handle, and/or we'd need to make the hard choice of only maintaining certain Android versions and skipping certain ones completely. It would also be very difficult to maintain fidelity. 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)

CameronNemo 6y ago
Have you considered https://anbox.io https://anbox.io ?
- lfy_google 6y ago
  Thanks, I've read about this before but just went over it again in more detail yesterday with a fresh look. 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).

krschultz 6y ago

The activities / fragment portion of the SDK is not owned by the team that builds Android Studio and the broader toolchain.

halfjew22 6y ago

I only see one reply remotely regarding Activites and Fragments and it's just asking what problems you had. It should be pretty obvious to anyone that's tinkered with Android that the whole battle between which to choose is ridiculous. 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.

matchbok 6y ago
Oh, my team has tried the new stuff. It's terrible. Especially with the viewmodel stuff. Hidden bugs, no documentation, constant API changes. Hell, you couldn't scope a viewmodel to a nav graph until recently, which defeats the entire purpose of the whole thing. It's just frustrating that 10 years later, we still have nothing that is remotely capable of the things an iOS ViewController can do.

on_and_off 6y ago

emulator vs simulator just offer different drawbacks. It would surely be nice to have the option but a good emulator is needed.