androi-Verifying App Behavior on the Android Runtime (ART)
2015-12-26 03:13
337 查看
With Android 4.4, we are beginning to roll out a new Android runtime, ART.
This runtime offers a number of new features that improve performance and smoothness of the Android platform and apps.
At this time, all devices still use Dalvik as the default runtime. We encourage you to test your apps
for ART compatibility and to take advantage of ART's new features. However, for the time being, you should also take care to maintain compatibility with Dalvik.
Most apps should just work when running with ART. However, some techniques that work on Dalvik do
not work on ART.
>Under Dalvik, apps frequently find it useful to explicitly call
prompt garbage collection (GC). This should be far less necessary with ART, particularly if you're invoking garbage collection to prevent
occurrences or to reduce fragmentation. You can verify which runtime is in use by calling
If ART is in use, the property's value is
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).
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
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
ART's JNI throws errors in a number of cases where Dalvik didn’t. (Once again, you can catch many
such cases by testing with CheckJNI.)
>In addition, the JNI functions
properly throw
of simply returning null. Similarly,
properly throw
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.
>
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
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.
In Java, review calls to the
that specify an explicit stack size. For example, you will need to increase the size if
In C/C++, review use of
to call JNI
ART's Ahead-Of-Time (AOT) Java compilation should work for all standard Java code. Compilation is performed by ART's
Problems) so we can fix them as quickly as possible. A couple of issues to note:
ART does tighter bytecode verification at install time than Dalvik does. Code produced by the Android build tools should be fine. However, some post-processing tools (especially tools that perform obfuscation) may produce invalid
files that are tolerated by Dalvik but rejected by ART. We have been working with tool vendors to find and fix such issues. In many cases, getting the latest versions of your tools and regenerating the DEX files can fix these problems.
Some typical problems that are flagged by the ART verifier include:
invalid control flow
unbalanced
0-length parameter type list size
Some apps have dependencies on the installed
optimized output directory. These files are now ELF files and not an extended form of DEX files. While ART tries to follow the same naming and locking rules as Dalvik, apps should not depend on the file format; the format is subject to change without notice.
If you run into any issues that aren’t due to app JNI issues, report them via the Android Open Source Project Issue Tracker at https://code.google.com/p/android/issues/list.
Include an
This runtime offers a number of new features that improve performance and smoothness of the Android platform and apps.
At this time, all devices still use Dalvik as the default runtime. We encourage you to test your apps
for ART compatibility and to take advantage of ART's new features. However, for the time being, you should also take care to maintain compatibility with Dalvik.
Most apps should just work when running with ART. However, some techniques that work on Dalvik do
not work on ART.
>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).
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
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.
ART's JNI throws errors in a number of cases where Dalvik didn’t. (Once again, you can catch many
such cases by testing with CheckJNI.)
>In addition, the JNI functions
GetFieldID()and
GetStaticFieldID()now
properly throw
NoSuchFieldErrorinstead
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.
>
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
Threadstack
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.
In Java, review calls to the
Threadconstructor
that specify an explicit stack size. For example, you will need to increase the size if
StackOverflowErroroccurs.
In C/C++, review use of
pthread_attr_setstack()and
pthread_attr_setstacksize()for threads that also run Java code via JNI. Here is an example of the error logged when an app attempts
to call JNI
AttachCurrentThread()when the pthread size is too small:
F/art: art/runtime/thread.cc:435] Attempt to attach a thread with a too-small stack (16384 bytes)
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 dex2oattool; if you encounter any issues related to
dex2oatat install time, let us know (seeReporting
Problems) so we can fix them as quickly as possible. A couple of issues to note:
ART does tighter bytecode verification at install time than Dalvik does. Code produced by the Android build tools should be fine. However, some post-processing tools (especially tools that perform obfuscation) may produce invalid
files that are tolerated by Dalvik but rejected by ART. We have been working with tool vendors to find and fix such issues. In many cases, getting the latest versions of your tools and regenerating the DEX files can fix these problems.
Some typical problems that are flagged by the ART verifier include:
invalid control flow
unbalanced
moniterenter/
moniterexit
0-length parameter type list size
Some apps have dependencies on the installed
.odexfile format in
/system/framework,
/data/dalvik-cache, or in
DexClassLoader’s
optimized output directory. These files are now ELF files and not an extended form of DEX files. While ART tries to follow the same naming and locking rules as Dalvik, apps should not depend on the file format; the format is subject to change without notice.
Reporting Problems
If you run into any issues that aren’t due to app JNI issues, report them via the Android Open Source Project Issue Tracker at https://code.google.com/p/android/issues/list.Include an
"adb bugreport"and a link to the app in the Google Play store if available. Otherwise, if possible, attach an APK that reproduces the issue. Note that issues (including attachments) are publicly visible.
相关文章推荐
- Android单张图片查看、单指移动、双指缩放、双击最大化或最小化
- Android 增量更新 -- 客户端bsdiff库的编译及jni调用
- Android之ListView的Adapter的复用
- android-Supporting Tablets and Handsets
- VMware 11 安装 ios 10 问题总结
- 用CheckBox实现自定义RatingBar
- android-Screen Compatibility Mode
- Android中修改ArrayAdapter字体以及颜色
- Android TextView
- Android逆向工程101 – Part 2
- android-Distributing to Specific Screens
- Android Reverse Engineering 101 – Part 1
- 微信浏览器里location.reload问题
- iOS Crash 崩溃日志总结
- 10.Android之ProgressDialog进度对话框学习
- Android App打包自动生成版本号Versin Name与Version Code方法之完美方案
- iOS TextField 获取光标的位置
- 【Android】《第一行代码—Android》第四章总结
- android 图片二次采样,质量压缩,LruCache缓存
- app包中的fragment和v4包中的fragment的使用的区别