Do you have a link to show how to do that? Sounds useful, but the only reference I've found to that is to do it from Visual Studio and using Xamarin C# and not 'native' Java.
Once you enable the container platform in windows, and enable the bios setting for virtualization, it should just work, when I get back to my home computer I will look the details
Alright, so I just made a run of it and verified it all works.
As you say, the tutorial from Microsoft is for VS[0], but it actually talks about the android emulator, which is the same thing that Android Studio uses, just make sure you update it to latest, atm it's 27.3.10
Admittedly, the startup time seems a bit longer than with HAXM, but otherwise the emulation is pretty responsive.
[0]https://docs.microsoft.com/en-us/xamarin/android/get-started...
Intel's HAXM is a lightweight hypervisor (supervisor in charge of VM supervisors) that is so lightweight because it is primarily a thin wrapper around hardware support (which should seem unsurprising given Intel's direct involvement), bypassing the Operating System (for the most part).
Microsoft's Hyper-V is the hypervisor platform built into modern versions of Windows and which shares/follows (for the most part) Microsoft's overall Platform APIs and Driver APIs, making for a better communication channel between Hyper-V and the usual Windows supervisors/kernels when hosting Windows virtual machines. (Similar to the integration services offered by other hypervisors like VirtualBox, with the "magic" that such services are easier because the OS and the hypervisor share very similar "languages" already.)
Microsoft's Hyper-V is also the base component for other systems such as the Windows Container Platform, some of Windows 10's more optional enterprise sandboxing systems, etc.
Why has this been downvoted? I like Android studio but you do need to have at least 32GB of RAM for it to feel snappy. 16GB gives you a very usable, but sometimes laggy experience.
I'm using almost daily Android studio on Celeron J3455 with 4GB ram on Ubuntu 16.04 64bit and it's usable. I mostly do WebView apps, it is also on some cheap SSD.
> I'm using almost daily Android studio on Celeron J3455 with 4GB ram on Ubuntu 16.04 64bit and it's usable. I mostly do WebView apps, it is also on some cheap SSD.
I don't think it's possible to run the emulator with more than 5 FPS with this kind of set up. Let alone the editor itself which frankly runs like crap on low end hardware. The irony is that eclipse was much much faster in constrained environments. It's like IntellJ spends its time indexing and when it's done it's doing some more indexing just for kicks.
You are probably not counting the Gradle daemon and kotlin compiler daemon. I have seen those grow to 4±GB and ~8GB respectively. Not using Kotlin definitely has advantages for memory usage.
16Gb, Standard HDD, Mid range i5 processor. It's sluggish as hell. Takes an age to start up, the gui is slow, and compiling even a basic app taks forever, with much disk thrashing.
I've given up, and recently uninstalled it. I'm going to try and develop android apps using Xamarin in Visual Studio instead (as I have that anyway for Windows dev).
I am on the same path, even though it makes me feel a bit like hypocrite given my advocacy for native tooling vs third party, it actually does seem a better path to sanity.
Either that or just live with mobile Web and its constraints.
I try Android Studio for a bit every now and then.
I have to say it's such a giant bloated thing that it really does not make me want to write native code.
Fortunately, there is a lot of great stuff going on with Progressive Web Apps now. I hope that they will be the future. Developing for the browser is so much leaner.
Developing for the browser is leaner but it's the opposite for end-users. I hope PWAs are the future as well but native is still king for the time being.
I open 2 web apps at the same time, and the phone crashes (all RAM exhausted). I open a web app, and it lags horribly for minutes before becoming even semi-usable.
This is on a Nexus 5X, using stock Android.
Web apps are a complete joke right now. Entirely useless. I always install native apps, if available — even if I know I’ll uninstall it 5 minutes later — because the alternative is entirely unusable on my device.
A web application burning through a ton of JavaScript and a very complex DOM can very easily start demanding a lot of CPU and RAM.
I've never had a browser crash a phone, but having the phone start to immediately feel sluggish after opening something like a moderately sized GitHub pull request--that's certainly a thing.
Perhaps android apps are relatively resource intensive or inefficient, but in terms of "web apps" like SPAs vs server rendered websites, web apps are doing more on the client. They inherently use more resources. Electron apps don't tend to have awful performance characteristics on the desktop just because they can't share the underlying Chrome instance, opening the same apps (like Slack) in the browser is only marginally better. And if native resource consumption on Android is really that bad, that would be pretty unique for that platform. iOS and desktop platforms definitely have much more efficient native apps than web apps.
However making it more difficult to crash the device is a definite advantage, you're right about that. Although I very rarely have native apps crash my devices anyways. I can't remember a time it's happened on my phone, and on my desktop it's usually a device driver issue combined with a game that causes an issue. Definitely an edge case and not something I encounter with native applications in general.
Too many websites at the same time cause the same issue.
If I open a site like cnn.com without an adblocker, all apps running in background (even e.g. spotify if I'm listening to music) are force closed because the phone runs low on RAM.
Every website or web app I've used so far has used > 100-200M RAM, while a well developed Android app stays below 20-50M.
My phone has 2GB RAM, 1GB is used by the OS, 500-800M are used by Google Play Services, and a web browser with 1-2 tabs takes another 200M of RAM.
As soon as I open a website any more complex than HN, everything feels sluggish.
Agreed. The DOM and JavaScript, as used by many heavy websites and web apps, are heavy.
On the other hand, JavaScript in a more constrained environment--React Native, for example--is a lot more reasonable. Still heavier than an Android app, but not so heavy that it kills processes except on very downmarket phones.
I've started using the YouTube website on iOS because it uses the native video player and is ad-free then (some people put an ad-break every few minutes on documentaries for example which is super annoying)
+1 dropped facebook native app for their web version. Never looked back.
I think the answer is some apps are better on web, others on native.
Videos / Music / Games / Email / Messaging are better native. For actual reading of content (HN / Reddit / Twitter / Facebook ...etc) I find better on the web.
Why, good you asked: a native app called NewPipe [1] which eats Youtube URL's and plays videos (and allows the download of such), no more - and that includes no ads - and no less. It only sends such data as needed to get the video. Lately it has started to support Soundcloud as well, I have not tried this yet.
> The privacy is much better.
Is it? I strongly challenge that at least in the iOS ecosystem. Sandboxing and privacy on the web is not as strong in many cases as iOS.
As a hypothetical user who doesn’t post on niche tech forums, I totally prefer a native app over a web app
It’s pretty
It’s fast
It’s not stuttery-stoppy
I can swipe back and forth between pages without waiting 4 seconds for everything to display, and then inevitably move around right before I fucking tap
It’s on the app store
I can use it instantly.
I can remove it instantly.
I don’t know what sandboxing is
I don’t care about privacy
There are convenient share buttons
I can use it on the single device I use regularly
I can screenshot it
I can unfortunately change the style by updating
It can use my battery when it’s closed? Wait wha-
ooh notification
...
I’m gonna go use facebook now like a normal person, later nerds
Every time I try to use Facebook app - on any platform - it breaks my workflow about 5 minutes in, because I can't post a link to a group (or another comment) in a comment.
Some kinds of things are just a better fit for the web.
I prefer native apps over web apps, but for most things I vastly prefer a website to both of those. I shouldn't have to install an app for every single thing I want to use, especially if I only use the thing once a week or so.
Actually, it makes me like Kotlin more than Swift and I’m macOS fan who happens to own an Android phone just for USB-C. It felt good when I published my first APK.
PWAs are the only way I can see mobile Web actually being comparable to native, specially when being able to use native APIs like on Windows and ChromeOS (eventually Android as well).
> I have to say it's such a giant bloated thing that it really does not make me want to write native code.
In what way? How?
Browser-based has the fast reload thing going for but it's not in the same universe as lean for a modern development stack, not in terms of RAM usage nor size on disk. So can you elaborate on this "bloated" vs. "lean"?
> I have to say it's such a giant bloated thing that it really does not make me want to write native code.
Why?
You can write (and compile, and test) native code without ever touching Android Studio. I would think any like/hate of IntelliJ (Android Studio) should have no bearing on whether you choose to write native Android code or not.
It would be like saying, "CLion is such a giant bloated thing that I never want to write C++ code". Or "RubyMine is so giant and bloated, I never want to touch Ruby on Rails again".
What would you say, for example, if someone told you they didn't want to write a Progressive Web App because they really disliked Atom and Visual Studio Code?
Hmm. I don't find that terribly masochistic. If you know the language, the basic java.* classes and your usual third parties libraries (guava, commons, etc.) well enough you can get a long way without and IDE. I've done a great deal of work -- typically maintenance and troubleshooting -- just cloning a repo and working in vim. I avoid any degree of dependence on IDEs for any part of building, packaging, etc. so... why bother with an IDE unless you really need IDE features?
and that's very often if you are a Java/Android dev. Even features like auto complete (let alone with prediction) is very hard to get right elsewhere, let's say, somewhere like Vim. Not just the language, there's Android SDK itself and other libraries. But, if you count "not needing auto complete etc" as part of "know the language well enough" or that they trivial enough then, well, I rest my case.
I wrote substantial systems before there were any Java IDEs. Nothing hard about it. Write a lot of code and it's easy. If that disturbs you I'm sorry, but you should allow that there are people with more skill than perhaps you've been exposed to.
No, it doesn't disturb me at all. At work and among friends there are people who have more skills than I am exposed to and I get to learn a lot from them. However none of them ever advocate not using an IDE or claim not needing an IDE. In fact a lot of them use one or the other.
I used to write in Vim (C) when I worked for that South Korean giant. After that I moved to Java/Android and I wouldn't get back to those days of Vim/C for anything. So I think it comes down to choice. The thing is GP commenter mentioned "masochism" and now I see the point.
I am talking strictly about Android Studio and not the end results i.e. the apps.
Giant? It's smaller than Xcode you know :)
Bloated? Yes, so bloated! As an Android developer this is my biggest complaint from the ecosystem after the fragmentation though Google is trying to fix that with Treble but they are just not enough for the Studio. It was amazingly frustrating and pathetic to work with it couple of years back and it still is.
My entire team is stuck on old Android Studio versions. I was the only one trying to live on the edge (and by that I mean stable channel) but for past few months I have just stopped upgrading Studio. It never fails to break the entire damn setup upon any upgrade. Like any release!
I had to copy the old ndk folder from a colleague's SDK and use it on mine after the update broke everything few weeks ago. I am not touching that thing again. Actually I am preparing myself to leave Android and get into backend dev, will keep in touch with Android dev as a hobby and maybe just to update my little used apps on PlayStore.
Most exciting feature: App Bundles! At last, users with an Galaxy S5 won't have to install the same APK as a Note S9. This will especially helpful to users in countries where data is expensive, phones are old, and storage is low. Also, I can see this ensuring users download through the app store, since app pirates (most of the time, injecting trojans into free programs), will have to upload many different APKs in order to "trick" users into installing their APK.
The Energy Profiler is a nice addition, but I wish there was some incentive for apps to be energy efficient (even an app store "badge" would be better than nothing), since people will continue to just blame Android for the battery performance and not the apps.
super-small-nit: It's Android Studio 3.2, but the installer's file name is android-studio-ide-181.5014246-mac.dmg. android-studio-3.2.dmg would of been just fine. I am guessing 181 is a build number, but as a user, I don't care about what build number it is.
181 is actually 20(18)1st release, following the underlying IDEA version. They lag behind one version, IDEA now is 182 and 183 is in early release program(eap)
One nice feature that's somewhat buried in the notes is that the linter can now warn against some Kotlin/Java interoperability problems. But you need to turn the new inspections on manually: https://developer.android.com/studio/releases/#lint
I have used IntelliJ IDEA since the early 2000's and used it for Android development since Android first came out.
It used to be an amazing experience, and when the news came out that Google was going to switch to IDEA for their official tools instead of going with that Eclipse I was thrilled. Finally everybody was going to able to know just how fast and efficient Android development can be.
How wrong I was. When Android Studio came out, it was incredible slow. Even today, after years of improvement to the developer experience it still isn't as efficient as plain IDEA was before Google created Android Studio.
I actually lay most of the blame on Gradle, which became mandatory around the same time. I never thought that someone would create a buid tool I dislike more than Maven, but it seems they succeeded.
Gradle is pure insanity. Take a JVM-based scripting language that no one uses, and base an entire build-tool around it - complete with a custom DSL - that is so slow it needs to be run in the background as a service to be even somewhat performant, and make sure that each new version somehow breaks older build scripts so that you're constantly being prompted to update, and then being prompted to fix whatever the update broke... It's honestly just pure, unadulterated, crap.
But you need to edit the Gradle configuration files. Most people simply cargo-cult that, and while that works most of the time, it's incredibly non-intuitive to solve problems.
99% of the time this is just pasting one dependency line into a file, and a Gradle file reads more intuitively than a Maven pom file. IMO performance aside Maven really only excels in edge cases. Most projects would never see any advantages from using Maven instead.
Honestly, I find Maven more intuitive. Gradle is too flexible, you can have dozens of way to perform one task. With maven, you often search for one plugin that does what you want and stick with that. Of course, if there's no existing plugin that fit you, then it gets much more complicated, but that case is usually rare due to maven's massive number of plugins.
You might need to wait for Flutter to mature. I presume they'll use a custom build tool instead of Gradle, and Dart as their build language instead of Apache Groovy.
> I actually lay most of the blame on Gradle, which became mandatory around the same time. I never thought that someone would create a build tool I dislike more than Maven, but it seems they succeeded
Indeed ... most people don't know Groovy and hate Gradle whenever they have to fight with the build file. What's fascinating is that I really like Groovy and know it extremely well - but even I hate Gradle. It's amazing how shiny the documentation looks for how little it explains the underlying principles of what is going on. Most people are two steps removed from any hope of understanding it (first learn Groovy, then realize that Gradle is actually a DSL layered on top of Groovy, so you still have no clue what is going on until you learn that as well ...)
In my opinion this a very exciting release.
Google is really pushing to make the platform better for everyone, users and developers.
Android App Bundles, Integration with Hyper-V and support for AMD are very welcome.
Just wish using Android Studio required less ram and CPU, but to be honest, IIRC developing with Java has always been a little demanding when it comes to machine resources.
There is quite a large downside to app bundles, that is that it requires you (the developer) to hand over your app signing key to Google. The fact that updates from the play store are signed end to end is pretty great in my opinion, this doesn't apply so much if you give away your signing key.
As far as I can tell it's not a technical reason why they ask for your key - bundletool [1] supports generating a set of signed APKs (.apks, APK set archive) in the same way the play store would from an app bundle. Android Studio's GUI could just as easily generate that to upload directly to the play store instead of an app bundle. This would net the same benefits to the end users and the same level of convenience to the developer, all whilst keeping your private keys private.
83 comments
[ 2.4 ms ] story [ 191 ms ] threadMicrosoft's Hyper-V is the hypervisor platform built into modern versions of Windows and which shares/follows (for the most part) Microsoft's overall Platform APIs and Driver APIs, making for a better communication channel between Hyper-V and the usual Windows supervisors/kernels when hosting Windows virtual machines. (Similar to the integration services offered by other hypervisors like VirtualBox, with the "magic" that such services are easier because the OS and the hypervisor share very similar "languages" already.)
Microsoft's Hyper-V is also the base component for other systems such as the Windows Container Platform, some of Windows 10's more optional enterprise sandboxing systems, etc.
I don't think it's possible to run the emulator with more than 5 FPS with this kind of set up. Let alone the editor itself which frankly runs like crap on low end hardware. The irony is that eclipse was much much faster in constrained environments. It's like IntellJ spends its time indexing and when it's done it's doing some more indexing just for kicks.
I've given up, and recently uninstalled it. I'm going to try and develop android apps using Xamarin in Visual Studio instead (as I have that anyway for Windows dev).
Either that or just live with mobile Web and its constraints.
How's your personal experience with Xamarin? How's the tooling compared to Android Studio?
I have to say it's such a giant bloated thing that it really does not make me want to write native code.
Fortunately, there is a lot of great stuff going on with Progressive Web Apps now. I hope that they will be the future. Developing for the browser is so much leaner.
Man .. don't even get me started .. ok, here we go:
I can use it instantly.
I can remove it instantly.
The sandboxing is much better.
The privacy is much better.
I can link to it from wherever I like.
I can use it on all my devices.
I can copy text and images.
I can change the style (I often enlarge the font for example).
It can not use my battery / camera / phone when it's closed.
...
I feel like I can go on forever.
This is on a Nexus 5X, using stock Android.
Web apps are a complete joke right now. Entirely useless. I always install native apps, if available — even if I know I’ll uninstall it 5 minutes later — because the alternative is entirely unusable on my device.
I've never had a browser crash a phone, but having the phone start to immediately feel sluggish after opening something like a moderately sized GitHub pull request--that's certainly a thing.
However making it more difficult to crash the device is a definite advantage, you're right about that. Although I very rarely have native apps crash my devices anyways. I can't remember a time it's happened on my phone, and on my desktop it's usually a device driver issue combined with a game that causes an issue. Definitely an edge case and not something I encounter with native applications in general.
If I open a site like cnn.com without an adblocker, all apps running in background (even e.g. spotify if I'm listening to music) are force closed because the phone runs low on RAM.
Every website or web app I've used so far has used > 100-200M RAM, while a well developed Android app stays below 20-50M.
My phone has 2GB RAM, 1GB is used by the OS, 500-800M are used by Google Play Services, and a web browser with 1-2 tabs takes another 200M of RAM.
As soon as I open a website any more complex than HN, everything feels sluggish.
On the other hand, JavaScript in a more constrained environment--React Native, for example--is a lot more reasonable. Still heavier than an Android app, but not so heavy that it kills processes except on very downmarket phones.
I think the answer is some apps are better on web, others on native.
Videos / Music / Games / Email / Messaging are better native. For actual reading of content (HN / Reddit / Twitter / Facebook ...etc) I find better on the web.
[1] https://newpipe.schabi.org/
It’s pretty
It’s fast
It’s not stuttery-stoppy
I can swipe back and forth between pages without waiting 4 seconds for everything to display, and then inevitably move around right before I fucking tap
It’s on the app store
I can use it instantly.
I can remove it instantly.
I don’t know what sandboxing is
I don’t care about privacy
There are convenient share buttons
I can use it on the single device I use regularly
I can screenshot it
I can unfortunately change the style by updating
It can use my battery when it’s closed? Wait wha-
ooh notification
...
I’m gonna go use facebook now like a normal person, later nerds
Some kinds of things are just a better fit for the web.
In what way? How?
Browser-based has the fast reload thing going for but it's not in the same universe as lean for a modern development stack, not in terms of RAM usage nor size on disk. So can you elaborate on this "bloated" vs. "lean"?
Why?
You can write (and compile, and test) native code without ever touching Android Studio. I would think any like/hate of IntelliJ (Android Studio) should have no bearing on whether you choose to write native Android code or not.
It would be like saying, "CLion is such a giant bloated thing that I never want to write C++ code". Or "RubyMine is so giant and bloated, I never want to touch Ruby on Rails again".
What would you say, for example, if someone told you they didn't want to write a Progressive Web App because they really disliked Atom and Visual Studio Code?
and that's very often if you are a Java/Android dev. Even features like auto complete (let alone with prediction) is very hard to get right elsewhere, let's say, somewhere like Vim. Not just the language, there's Android SDK itself and other libraries. But, if you count "not needing auto complete etc" as part of "know the language well enough" or that they trivial enough then, well, I rest my case.
I wrote substantial systems before there were any Java IDEs. Nothing hard about it. Write a lot of code and it's easy. If that disturbs you I'm sorry, but you should allow that there are people with more skill than perhaps you've been exposed to.
I used to write in Vim (C) when I worked for that South Korean giant. After that I moved to Java/Android and I wouldn't get back to those days of Vim/C for anything. So I think it comes down to choice. The thing is GP commenter mentioned "masochism" and now I see the point.
HAHAHAHAHAHA
Web apps are the most bloated thing I can imagine. Don't know what you are talking about
Supported by VSCode and IntelliJ community edition. Hot reload is the cat's PJs.
Giant? It's smaller than Xcode you know :)
Bloated? Yes, so bloated! As an Android developer this is my biggest complaint from the ecosystem after the fragmentation though Google is trying to fix that with Treble but they are just not enough for the Studio. It was amazingly frustrating and pathetic to work with it couple of years back and it still is.
My entire team is stuck on old Android Studio versions. I was the only one trying to live on the edge (and by that I mean stable channel) but for past few months I have just stopped upgrading Studio. It never fails to break the entire damn setup upon any upgrade. Like any release!
- Stable releases of Android Studio are usually followed by complaints of breaking left and right even though they take mounths to get out
- Stable releases of Android Support Library usually always have a couple of regressions
- Documentation and release notes always gets made available a couple of hours later
- Kotlin plugin usually breaks at every release
- NDK gets the attention level of a 20% project
https://jaxenter.com/android-studio-dumps-eclipse-for-intell...
The Energy Profiler is a nice addition, but I wish there was some incentive for apps to be energy efficient (even an app store "badge" would be better than nothing), since people will continue to just blame Android for the battery performance and not the apps.
super-small-nit: It's Android Studio 3.2, but the installer's file name is android-studio-ide-181.5014246-mac.dmg. android-studio-3.2.dmg would of been just fine. I am guessing 181 is a build number, but as a user, I don't care about what build number it is.
While Xcode on the other hand 3-4 years ago it was liked developed by interns. But Xcode 9-10 has been very fast and less buggy on my 16GB.
Developing for Android is not fun anymore for me. It is getting bloated.
It used to be an amazing experience, and when the news came out that Google was going to switch to IDEA for their official tools instead of going with that Eclipse I was thrilled. Finally everybody was going to able to know just how fast and efficient Android development can be.
How wrong I was. When Android Studio came out, it was incredible slow. Even today, after years of improvement to the developer experience it still isn't as efficient as plain IDEA was before Google created Android Studio.
I actually lay most of the blame on Gradle, which became mandatory around the same time. I never thought that someone would create a buid tool I dislike more than Maven, but it seems they succeeded.
Indeed ... most people don't know Groovy and hate Gradle whenever they have to fight with the build file. What's fascinating is that I really like Groovy and know it extremely well - but even I hate Gradle. It's amazing how shiny the documentation looks for how little it explains the underlying principles of what is going on. Most people are two steps removed from any hope of understanding it (first learn Groovy, then realize that Gradle is actually a DSL layered on top of Groovy, so you still have no clue what is going on until you learn that as well ...)
Android App Bundles, Integration with Hyper-V and support for AMD are very welcome.
Just wish using Android Studio required less ram and CPU, but to be honest, IIRC developing with Java has always been a little demanding when it comes to machine resources.
As far as I can tell it's not a technical reason why they ask for your key - bundletool [1] supports generating a set of signed APKs (.apks, APK set archive) in the same way the play store would from an app bundle. Android Studio's GUI could just as easily generate that to upload directly to the play store instead of an app bundle. This would net the same benefits to the end users and the same level of convenience to the developer, all whilst keeping your private keys private.
[1] https://developer.android.com/studio/command-line/bundletool