Skip to content

Most visited

Recently visited


Verifying App Behavior on the Android Runtime (ART)

The Android runtime (ART) is the default runtime for devices running Android 5.0 (API level 21) and higher. This runtime offers a number of features that improve performance and smoothness of the Android platform and apps. You can find more information about ART's new features in Introducing ART.

However, some techniques that work on Dalvik do not work on ART. This document lets you know about things to watch for when migrating an existing app to be compatible with ART. Most apps should just work when running with ART.

Addressing Garbage Collection (GC) Issues

Under Dalvik, apps frequently find it useful to explicitly call System.gc() to prompt garbage collection (GC). This should be far less necessary with ART, particularly if you're invoking garbage collection to prevent GC_FOR_ALLOC-type occurrences or to reduce fragmentation. You can verify which runtime is in use by calling System.getProperty("java.vm.version"). If ART is in use, the property's value is "2.0.0" or higher.

Furthermore, a compacting garbage collector is under development in the Android Open-Source Project (AOSP) to improve memory management. Because of this, you should avoid using techniques that are incompatible with compacting GC (such as saving pointers to object instance data). This is particularly important for apps that make use of the Java Native Interface (JNI). For more information, see Preventing JNI Issues.

Preventing JNI Issues

ART's JNI is somewhat stricter than Dalvik's. It is an especially good idea to use CheckJNI mode to catch common problems. If your app makes use of C/C++ code, you should review the following article:

Debugging Android JNI with CheckJNI

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).

One area to watch for in particular is the use of Get...ArrayElements() and Release...ArrayElements() functions. In runtimes with non-compacting GC, the Get...ArrayElements() functions typically return a reference to the actual memory backing the array object. If you make a change to one of the returned array elements, the array object is itself changed (and the arguments to Release...ArrayElements() are usually ignored). However, if compacting GC is in use, the Get...ArrayElements() functions may return a copy of the memory. If you misuse the reference when compacting GC is in use, this can lead to memory corruption or other problems. For example:

Error handling

ART's JNI throws errors in a number of cases where Dalvik doesn’t. (Once again, you can catch many such cases by testing with CheckJNI.)

For example, if RegisterNatives is called with a method that does not exist (perhaps because the method was removed by a tool such as ProGuard), ART now properly throws NoSuchMethodError:

08-12 17:09:41.082 13823 13823 E AndroidRuntime: FATAL EXCEPTION: main
08-12 17:09:41.082 13823 13823 E AndroidRuntime: java.lang.NoSuchMethodError:
    no static or non-static method
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
    at java.lang.Runtime.nativeLoad(Native Method)
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
    at java.lang.Runtime.doLoad(
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
    at java.lang.Runtime.loadLibrary(
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
    at java.lang.System.loadLibrary(

ART also logs an error (visible in logcat) if RegisterNatives is called with no methods:

W/art     ( 1234): JNI RegisterNativeMethods: attempt to register 0 native
methods for <classname>

In addition, the JNI functions GetFieldID() and GetStaticFieldID() now properly throw NoSuchFieldError instead of simply returning null. Similarly, GetMethodID() and GetStaticMethodID() now properly throw NoSuchMethodError. This can lead to CheckJNI failures because of the unhandled exceptions or the exceptions being thrown to Java callers of native code. This makes it particularly important to test ART-compatible apps with CheckJNI mode.

ART expects users of the JNI CallNonvirtual...Method() methods (such as CallNonvirtualVoidMethod()) to use the method's declaring class, not a subclass, as required by the JNI specification.

Preventing Stack Size Issues

Dalvik had separate stacks for native and Java code, with a default Java stack size of 32KB and a default native stack size of 1MB. ART has a unified stack for better locality. Ordinarily, the ART Thread stack size should be approximately the same as for Dalvik. However, if you explicitly set stack sizes, you may need to revisit those values for apps running in ART.

Object model changes

Dalvik incorrectly allowed subclasses to override package-private methods. ART issues a warning in such cases:

Before Android 4.1, method void
would have incorrectly overridden the package-private method in

If you intend to override a class's method in a different package, declare the method as public or protected.

Object now has private fields. Apps that reflect on fields in their class hierarchies should be careful not to attempt to look at the fields of Object. For example, if you are iterating up a class hierarchy as part of a serialization framework, stop when

Class.getSuperclass() == java.lang.Object.class
instead of continuing until the method returns null.

Proxy InvocationHandler.invoke() now receives null if there are no arguments instead of an empty array. This behavior was documented previously but not correctly handled in Dalvik. Previous versions of Mockito have difficulties with this, so use an updated Mockito version when testing with ART.

Fixing AOT Compilation Issues

ART's Ahead-Of-Time (AOT) Java compilation should work for all standard Java code. Compilation is performed by ART's dex2oat tool; if you encounter any issues related to dex2oat at install time, let us know (see Reporting Problems) so we can fix them as quickly as possible. A couple of issues to note:

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields


Follow Google Developers on WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience. (April 2018 — Developer Survey)