I've been seeing reports (rumours) that soon Android will be switching from Dalvik to ART as it's default runtime. I have no real idea what that means, my guess the runtime is (kind of?) like the operation system.
My app doesn't do anything particularly special/unique in the sense of mostly it makes HTTP requests for data, and uses LocationListeners a few times.
On some articles I've read about the rumored change, I've seen some people saying things along the lines of "I like ART, I'd use it right now if X app supported it". (One app I remember being mentioned is Xposed)
I've switched my phone to ART, and my app seems to work fine, so I'm guessing the answer to the title question is no, but I'm curious as to how the Xposed app isn't compatible. What have they done (or not done) to make their app not work in ART?
ART is a different runtime for Android applications. All android apps run inside of a virtual machine, much like java code runs in the Java VM.
Classically, when you compiled an Android app, it would compile to Dalvik byte code, designed to run in the Dalvik runtime (virtual machine).
In Android Kitkat though, Google introduced a new experimental runtime called Android Runtime, or ART. This is a different virtual machine, a re-implementaton of the runtime for Android applications to help fix some of the fundamental flaws in the original design.
ART offers several advantages over Dalvik:
Ahead-of-time (AOT) compilation
Improved garbage collection
Development and debugging improvements
Support for sampling profiler
Support for more debugging features
Improved diagnostic detail in exceptions and crash reports
It should also help with things like the DEX limit.
As to your question, you do not need to do anything as a developer. Google has said plainly that "Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications".
Google has announced at Google I/O 2014 that in the Android "L" release and beyond, that ART will replace Dalvik.
ART has now replaced Dalvik on the Nexus devices, and my six existing apps, available in the Google Store, all now fail to run. I see multiple lists of questions about ART causing app failures. I suspect the "new and improved" memory managment garbage-collection is the root cause of much of this. My Samsung devices did not have an option to select ART instead of Dalvik, so I am only now getting user reports of the failures under Android 5.x. It is reported that the implementation of the native interface is significantly less forgiving, and requires different and more explicitly defined global pointers, where previously local pointers would operate correctly. This means anyone using native code, and the JNI (native interface), may have to re-code their app, or target a different platform with a more stable system architecture.
Related
I am currently exploring garbage collection on Android. I want to know which garbage collection exactly (ART or Dalvik or whatever else) is used on my phone (Pixel 2, Android 10) so I can read up on how it works (e.g. if it uses a generational approach etc.) So, how can I find out which garbage collection my phone uses?
ART has been the Android runtime on Android devices since Android 5.0.
Note that ART's GC algorithms get tweaked every so often, just as Dalvik's were.
What is Dalvik?
Dalvik is a Just In Time (JIT) compiler. By the term JIT, we mean to say that whenever you run your app in your mobile device then that part of your code that is needed for execution of your app will only be compiled at that moment and rest of the code will be compiled in the future when needed.
What is ART?
ART or Android Runtime is an Android runtime that uses Ahead Of Time(AOT). By using AOT, what is does is it converts or compiles the whole High-level language code into Machine level code and at the time of installation of the app and not dynamically as the application runs(like in case of Dalvik).
Conclusion
Dalvik uses JIT and have a lot of drawbacks that were replaced by ART. So, from Android 4.4(Kitkat) ART was introduced as runtime and finally from Android 5.0(Lollipop), the Dalvik was completely replaced by ART by Android.
About your phone
Pixel 2, Android 10 is above Android Version 5.0, so it is definitely using ART.
The next version of my app has roughly 70K methods.
Knowing the exact implications of using Multidex (which usually means using the Multidex support library to support API<21) is important to me to make this decision:
Should I put a lot of effort (i.e. by fine tuning my Proguard configuration to shrink more aggressively, dumping some 3rd party libs etc.) to comply with the 64K methods limit, or should I just enable Multidex?
The documentation suggests that the Multidex support library may have some serious side effects (see Limitations of the multidex support library).
What should I really expect?
Failed installs on some devices?
Slow startup of the app (on 1st startup or always)?
New crashes or ANRs on some devices?
Overall performance degradation?
Feedback from your own migrations to Multidex would be greatly appreciated.
I'm not a specialist in Dalvik but I've worked on several projects that at some point required MultiDex and these are some of the lessons I learned:
Failed installs on some devices?
Some devices, specially old Gingerbread phones (but also ICS), use a very small LinearAlloc buffer which might cause errors while installing or cold-starting an app that has too many classes or whose class hierarchy is too complex. Enabling MultiDex doesn't contribute directly to this problem but allows developers to continue the "code bloat" up to the point where the app becomes too big to run on those devices... which sometimes only gets noticed when hundreds of very sad users start calling your customer support.
Slow startup of the app (on 1st startup or always)?
The first start after installing or upgrading is definitely slower, mainly due to the expensive I/O operations required to extract the secondary dex files from the APK into the file system. Subsequent starts are also affected proportionally to the size and complexity of classes that have to be loaded in order to bring up your first Activity, so it's good to keep the main components of the app (specially activities) in the primary dex to minimize startup time, although it's not always possible to do so.
New crashes or ANRs on some devices?
We've seen ANRs in Alcatel OneTouch (2.3.3) and Google Nexus One (2.3.6) phones that were caused by the dex extraction taking too long. In more modern devices, upgrading and cold starting multidex apps might take a bit longer but usually not long enough to cause ANRs.
Overall performance degradation?
Class loading becomes much slower and that affects the app in unpredictable ways. If you use a DI system, Protobuf or some other framework that generates hundreds of classes then you might find some of your application workflows becoming 20-25% slower after enabling multidex. One way to mitigate this is to load classes ahead of time via, for example, a background thread or a BroadcastReceiver but these, of course, will increate the memory footprint of the app and potentially slow down the device.
Also, some install-time dex optimizations might also be skipped if dexopts finds classes missing from the primary dex, so there might be a considerable penalty in terms of CPU and memory usage even if only a couple of classes end up in secondary dex files.
Should I put a lot of effort (i.e. by fine tuning my Proguard configuration to shrink more aggressively, dumping some 3rd party libs etc.) to comply with the 64K methods limit, or should I just enable Multidex?
MultiDex solves the 64K method limit but it's not a silver bullet and IMHO shouldn't be used as an excuse to avoid optimizing the size of the APK but if
You're only targeting modern devices (e.g. API 16+)
Performance/cold-start times are not critical
You have no time to optimize the app further
then MultiDex might be suitable, otherwise stripping unnecessary code is the way to go.
I ended up going with multidex, essentially because the roadmap of my app would have forced me to do so eventually (as I'm planning to integrate big libraries in a near future).
It's been more than a month and hundreds of thousands of installs/updates of the multidexed APK, so I can now say with decent confidence that the move to multidex did not have any significant side effect, in my specific case.
(note: the update only targetted API 11+, so I cannot speak of potential problems with Android 2.x).
Google added a new ART runtime with Android 4.4. How can I target my apk to both ART runtime and Dalvik runtime?
This change is without consequences for the developers. Your app remains exactly the same, nothing to do there. Just make sure you target API 19 so that your app is available for KitKat users. They will decide in their phone if they want to use ART or Dalvik.
This is an old question now, but very key. I confirmed today, all my apps break with ART+Android-5 on Nexus-x tablets. ART does more strict JNI checks, so if your app uses java plus native code,the move from Dalvik to ART may break app operation. For me, it has been a complete show-stop. I have 6 apps in Google Store and all fail now on Nexus devices running Android 5.x, yet they run correctly on all 4.x.x (Kitkat) series devices. This is most frustrating. I am going thru all the ART/ Dalvik questions and answers on this site. ART and Android-5.x is very significant change, so the question asked here "How do I target my apk to both Dalvik and ART?" is a key and very critical question. Time has proven that the responses given suggesting "No difference to developers" is manifestly incorrect. It certainly is in our case.
Two specific issues are documented, and I quote from "Verifying App Behavior on the Android Runtime (ART)":
1) " Checking JNI code for garbage-collection issues
ART has a compacting garbage collector under development on the Android Open Source Project (AOSP). Once the compacting garbage collector is in use, objects may be moved in memory. If you use C/C++ code, do not perform operations that are incompatible with compacting GC. We have enhanced CheckJNI to identify some potential issues (as described in JNI Local Reference Changes in ICS)." In other words, the new ART memory mangement model may break your existing (and operational) native code.
2) " Error handling
ART's JNI throws errors in a number of cases where Dalvik didn’t.".
A limited explanation of some of the issues that will cause errors to be thrown by the Android 5.x ART is provided in: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues
The forward-compatibility solution currently being adopted among users of Android devices running ART and 5.x, and facing non-operational apps, is a downgrade to Android 4.4.4, by unlocking the bootloader, wiping the device memory, and installing system image "Hammerhead", in the case of those running Nexus series tablets. For Samsung tablets, a tutorial is available at: http://forums.androidcentral.com/samsung-galaxy-s5/489071-tutorial-downgrade-samsung-galaxy-s5-5-0-4-4-kitkat.html
The dalvik or ART is only the runtime in the Android. As an app developer, you don't have to care about these differences. All you have to care about is your app's API level which is describing the dependence of the Android OS version.
And in Android 4.4, ART is only a development which is NOT the default runtime even if the release note describing that ART will make app use less memory and run quickly. If you want to find the different, you can wait for the next version of Android. In the opensource, I found the ART has been setting the default runtime selection.
For most apps ART will work just fine.
It is, however, not 100% compatible as something that work on Dalvik may not work on ART
Please visit this link for more information.
I am developing a rather large software on Android with a log native code, it's working now but having some performance issues.
I am hoping I can profile each module(function call) of the software for CPU cycles, memory usage, etc, on several real android phones. Is there a simple c library to do that?
I see people using oprofile, It seems to be a overkill for my case since that it is a system wild profiler, and it requires rebuild the kernel and system image.
As I have the full source code of my app, all I really need is a simple c library that I can embed in my code to do some profiling while the app runs several test cases.
BTW, what is the Linux way of doing this?
I've had pretty decent results with android-ndk-profiler.
http://code.google.com/p/android-ndk-profiler/
Outputs /mnt/sdcard/gmon.out
I am developing a rather large software on Android with a log native code, it's working now but having some performance issues.
I am hoping I can profile each module(function call) of the software for CPU cycles, memory usage, etc, on several real android phones. Is there a simple c library to do that?
I see people using oprofile, It seems to be a overkill for my case since that it is a system wild profiler, and it requires rebuild the kernel and system image.
As I have the full source code of my app, all I really need is a simple c library that I can embed in my code to do some profiling while the app runs several test cases.
BTW, what is the Linux way of doing this?
I've had pretty decent results with android-ndk-profiler.
http://code.google.com/p/android-ndk-profiler/
Outputs /mnt/sdcard/gmon.out