0

So, to properly disable ART runtime, you add android:vmSafeMode="true" to your application's manifest tag.

The issue I am having personally is that I develop an Android Library, and thus I do not have an application tag.

This means that my debugging is extremely slow when using instant run (dex2oat has to run over everything), or when someone using the library is using instant run.

I attempted to use manifestPlaceholders = [vmSafeModeEnabled: "true"] in my build.gradle, however this has no effect.

Anyone have any insights?

Similarly, 

dexOptions {
    preDexLibraries false
}

Yielded no difference in results. I am still seeing dex2oat taking a significant amount of time on each app startup.

Of course, all of these options work fine on applications, but not at all for library/SDK development.

Vic Vuci
  • 6,993
  • 6
  • 55
  • 90
  • Instant run have nothing to do with vmSafeMode. vmSafeMode is how the device will process/execute the code and Instant Run is a feature. If you want to disable instant run you can simply go to settings and disable it. – Budius Jun 01 '16 at 21:43
  • @Budius Not really sure where you're getting your information on that one. The way Instant Run works is that it pre-dexes things with the ART runtime. Essentially, the app that is installed via instant run will have a bunch of dex files which are slices of your application and its libraries. When the app opens, dex2oat runs and compiles those dexfiles on the fly. vmSafeMode determines if JIT (dalvik) or AOT (ART) compiling will take place. With vmSafeMode true, AOT wont occur, thus no slowdown. The reason this is an issue is that libraries cant specify this, whereas apps can. – Vic Vuci Jun 06 '16 at 17:28
  • it's been widely announced that instant run works all the way back to (if I'm not mistaken) API16. Yes, it does it by creating a multidex project and sending small Dex to the device during run time. But still had nothing to do with on-device vmSafeMode – Budius Jun 06 '16 at 17:33
  • While one could simply disable instant run, if there is a library that is setup with ART compilation as a dependency, it causes issues. You can't tell people to simply not use instant run when the issue is not inherently within it. – Vic Vuci Jun 06 '16 at 17:34
  • @Budius try it yourself. Turn vmSafeMode on and use instant run -- your app start time will be a lot faster. I mean, instant run doesn't technically work properly in this case, but it proves a point. You've yet to answer my question. – Vic Vuci Jun 06 '16 at 17:35
  • I believe you have mixed several different concepts and how they relate to each, I'll post an answer that does not directly answer your question, but should help better understand what each thing is or does. – Budius Jun 06 '16 at 18:22
  • @Budius feel free to email me (email is on my GH). Would love to learn. – Vic Vuci Jun 06 '16 at 18:30

1 Answers1

4

as I mention on the comment, I believe you're mixing some concepts so I'll take the time to explain them separately.

Instant Run

That is a feature of the IDE (that is Android Studio) and it is compatible (in different amounts) all the way back to devices running API 15. It only affects the code used during debug/development of the application.

It works by forcing the debug version of the app to be multidex and dynamic loading the code change over USB from a new dex file. The final compiled code (regardless of library or application) is never changed by this feature.

See here: https://developer.android.com/studio/run/index.html#instant-run

Instant Run is supported only when you deploy the debug build variant, use Android Plugin for Gradle version 2.0.0 or higher, and set minSdkVersion to 15

ART

That is the current runtime that Android runs. That is the core system that reads the byte code from the APK and turns it into processor instructions.

See here: https://source.android.com/devices/tech/dalvik/

ART and Dalvik are compatible runtimes running Dex bytecode, so apps developed for Dalvik should work when running with ART

So there're some edge cases differences, but if you check this link (https://developer.android.com/guide/practices/verifying-apps-art.html) you'll see that mostly are dealing with native code and wouldn't make difference for java only libraries.

That means that as long as the code targets the corrects APIs, it makes no difference which runtime it is executing the code as they're compatible runtimes.

vmSafeMode

On ART, this only disables the AOT compiler. From a normal user perspective that is the time during installation from Play Store that shows "installing". That is the moment when ART is doing several pre-processing on the app to be ready to be executed by the processor. This time also happens during USB debugging, but if disabled, it will have to execute on the fly.

preDexLibraries

This only tells the build system (gradle) to pre-process the libraries. That is helpful in cases whenever it's going to build the apk, the library is already processed. But if you're building a library, every time you change its code it will have to be re-processed anyway.

To your problem

With those concepts in place, I would like to point a the incoherence from the following comment below:

While one could simply disable instant run, if there is a library that is setup with ART compilation as a dependency, it causes issues. You can't tell people to simply not use instant run when the issue is not inherently within it.

  • a library is never compiled with the runtime as a dependency. It might depend on certainly API level (which methods it can call) or certain device feature (needs GPS or accelerator). The runtime (ART and Dalvik) are compatible and will execute the same code with the same result (ART being more efficient/faster).
  • also, as explained, instant run is a feature of Android Studio during your development/debugging. After the library have been packed into an aar file and other developers are using, it makes no difference if instant run was used or not.

With all that and your original problem in mind. I can see that due to the way instant run works, developing a library can have the reverse effect wanted from it. As a library could potentially be spread around the app and any change would force a new full build, thus taking longer.

Also I can see how disabling ahead-of-time compilation on ART could change dev-debug time, but only for for much.

to finalise

I hope all is clear and a solution for your problem is:

  • if Instant Run is taking too long, just disable it on your AndroidStudio. It will not influence any other developers.
  • I don't believe it will make any big difference, but if you insist, you can add vmSafeMode to your "sample app" while developing the library, and the library will still work on other apps developed by other developers without issues.
  • preDexLibraries is expected to have little impact when developing a library
Budius
  • 39,391
  • 16
  • 102
  • 144