ART on supported devices versus ART on pre-built images

Question

There are several applications that we have in the Play Store. As a preparatory test to the new Lollipop release, I wanted to see where our applications stood.

The first approach that I took was to take the Samsung Google Edition S4 and tell it to enable and reboot with the ART runtime environment (also available on our Nexus 5). This enlightened me to a couple issues that I could resolve going forward when this is official for the Nexus 9 release.

Then however, a build was released to push Lollipop 5.0 to the Nexus 7. Pushing it there provided me with additional issues. However, the printouts seem related to ART still. Such as:

11-03 09:22:29.419: E/art(6256): Tried to mark 0xfe80a920 not contained by any spaces
11-03 09:22:29.419: E/art(6256): Attempting see if it's a bad root
11-03 09:22:29.420: A/art(6256): art/runtime/gc/collector/mark_sweep.cc:381] Can't mark invalid object

followed by a crash.

Have you guys found that certain features of ART interact differently between the way that it interacts with 5.0+ instead of those before 5.0? Perhaps there are even stricter requirements on the recent operating system that are causing this.

I hadn't worked with these downloadable builds before a release before. Are they reliable in comparison with the actual release that is to come?

UPDATE

The issue has been resolved and did have something to do along the lines of the misuse of certain method calls into java objects from native code. Since I was able to work around needing to even make these calls in the first place, I just removed this code segment on this particular native code segment and did in Java instead.

It did not seem to be a problem in the native code since breakpoints were received after the native code, but apparently at some point down the line later it caused some undetermined crash at a later given point in time. Perhaps simply by design of how ART works in comparison to Dalvik.

Answer 1

if you are using native C/C# code check if uses GetArrayElements and ReleaseArrayElements and replace it with: GetArrayRegion:

There is an alternative to calls like GetArrayElements and GetStringChars that may be very helpful when all you want to do is copy data in or out. Consider the following:

jbyte* data = env->GetByteArrayElements(array, NULL);
if (data != NULL) {
    memcpy(buffer, data, len);
    env->ReleaseByteArrayElements(array, data, JNI_ABORT);
} This grabs the array, copies the first len byte elements out of it, and then releases the array. Depending upon the implementation,

the Get call will either pin or copy the array contents. The code copies the data (for perhaps a second time), then calls Release; in this case JNI_ABORT ensures there's no chance of a third copy.

One can accomplish the same thing more simply:

env->GetByteArrayRegion(array, 0, len, buffer); This has several advantages:

Requires one JNI call instead of 2, reducing overhead. Doesn't require pinning or extra data copies. Reduces the risk of programmer error — no risk of forgetting to call Release after something fails. Similarly, you can use the SetArrayRegion call to copy data into an array, and GetStringRegion or GetStringUTFRegion to copy characters out of a String.

More info: http://developer.android.com/training/articles/perf-jni.html#region_calls