<story><title>Android Studio 4.0</title><url>https://android-developers.googleblog.com/2020/05/android-studio-4.html</url></story><parent_chain><item><author>lfy_google</author><text>I&amp;#x27;m on the emulator team; we&amp;#x27;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&amp;#x27;s version of Android, with all java&amp;#x2F;C userspace APIs, to all wanted host OSes. This would require much greater resources dedicated to this porting than we&amp;#x27;re able to handle, and&amp;#x2F;or we&amp;#x27;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.&lt;p&gt;With full virtualization, the contact surface is restricted to a few low level bits in the kernel along with a few HALs&amp;#x2F;drivers that need to talk to the host for meaningful&amp;#x2F;fast I&amp;#x2F;O, like input&amp;#x2F;network&amp;#x2F;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&amp;#x2F;macos&amp;#x2F;linux easily, and it&amp;#x27;s how we&amp;#x27;ve been able to keep up with the pace of yearly Android releases.&lt;p&gt;Edit: Oh and note that we are totally aware of and bummed out by emulator&amp;#x27;s increasing resource usage as android version bumps up, to the point we&amp;#x27;re afraid that the next one will finally be the one that really needs all resources of a modern PC; as such, we&amp;#x27;re looking into ways to minimize the cpu&amp;#x2F;ram&amp;#x2F;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&amp;#x2F;promoting more stock AOSP images in the case where GMS isn&amp;#x27;t needed)</text></item><item><author>matchbok</author><text>Did they build a real simulator yet, like iOS? Note, not an emulator, which does hardware stuff. A simulator, so we don&amp;#x27;t have to use up our entire machine to run another operating system just to run a java app.&lt;p&gt;Or finally fix the activities and fragment mess?</text></item></parent_chain><comment><author>pjmlp</author><text>As anecdote I don&amp;#x27;t run the emulator since years, as I am not going to buy a last generation PC to keep running it at average speeds.&lt;p&gt;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.&lt;p&gt;Not everyone has Google level budgets for hardware.</text></comment>
<story><title>Android Studio 4.0</title><url>https://android-developers.googleblog.com/2020/05/android-studio-4.html</url></story><parent_chain><item><author>lfy_google</author><text>I&amp;#x27;m on the emulator team; we&amp;#x27;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&amp;#x27;s version of Android, with all java&amp;#x2F;C userspace APIs, to all wanted host OSes. This would require much greater resources dedicated to this porting than we&amp;#x27;re able to handle, and&amp;#x2F;or we&amp;#x27;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.&lt;p&gt;With full virtualization, the contact surface is restricted to a few low level bits in the kernel along with a few HALs&amp;#x2F;drivers that need to talk to the host for meaningful&amp;#x2F;fast I&amp;#x2F;O, like input&amp;#x2F;network&amp;#x2F;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&amp;#x2F;macos&amp;#x2F;linux easily, and it&amp;#x27;s how we&amp;#x27;ve been able to keep up with the pace of yearly Android releases.&lt;p&gt;Edit: Oh and note that we are totally aware of and bummed out by emulator&amp;#x27;s increasing resource usage as android version bumps up, to the point we&amp;#x27;re afraid that the next one will finally be the one that really needs all resources of a modern PC; as such, we&amp;#x27;re looking into ways to minimize the cpu&amp;#x2F;ram&amp;#x2F;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&amp;#x2F;promoting more stock AOSP images in the case where GMS isn&amp;#x27;t needed)</text></item><item><author>matchbok</author><text>Did they build a real simulator yet, like iOS? Note, not an emulator, which does hardware stuff. A simulator, so we don&amp;#x27;t have to use up our entire machine to run another operating system just to run a java app.&lt;p&gt;Or finally fix the activities and fragment mess?</text></item></parent_chain><comment><author>airstrike</author><text>If we&amp;#x27;re all throwing spaghetti at the wall here, what do I know, but maybe create an android-sdk OS that one may boot into and is heavily optimized for (speedy) android development?</text></comment>