Over a million developers have joined DZone.

Android Operating System Specific Crashes

In this article, we dive into a few example Android OS bugs, analyze the cause of the issues, and discuss strategies to mitigate the problems.

· Mobile Zone

Each major release of iOS and Android brings with it new bugs that impact only that respective OS version. We tasked our data science team with finding these bugs, and we first reported on initial findings in our Google IO data report. In this article, we dive into a few example Android OS bugs, analyze the cause of the issues, and discuss strategies to mitigate the problems. Finally, we recommend which Android version your app should support for optimal backwards compatibility.

3D Robot with colored wires

Android 6.0 (Marshmallow)
java.lang.SecurityException : this is followed by a message about the specific permission you are requesting. For example:
my location requires permission ACCESS_FINE_ LOCATION or ACCESS_COARSE_LOCATION
user ##### nor current process has android.permission.READ_PHONE_STATE

This exception is related to the new runtime permission system in Android 6 Marshmallow, causing issues for developers. Developers should now check if a permission is granted at runtime using checkSelfPermission() and request permissions using requestPermissions().

A particularly tricky problem occurs when you need access to external storage. The error that manifests isn’t as clear as the above examples. If you do need access to external storage, keep in mind that since these are considered dangerous permissions in the new permission system, you must also request them at runtime:

android.Manifest.permission.READ_EXTERNAL_STORAGE, android.Manifest.permission.WRITE_EXTERNAL_STORAGE

Android 6.0 & Android 5.0:
WebViews
java.lang.NoClassDefFoundError on the android/webkit/WebViewFactory$Preloader
Failed to list WebView package libraries for loadNativeLibrary android.content.pm.PackageManager$NameNotFoundException: com.google.android.webview

https://bugs.chromium.org/p/chromium/issues/detail?id=506369
This is caused by the WebView package updating via Google Play as someone tries to use an app that leverages a WebView. This is definitely an edge case as a user will need to attempt to use your app during this update process. It’s possible to handle this error, notify the user of the update, and then restart an activity once the WebView is available. Google has indicated they have no plans to fix this issue for now.

Android 5.0 (Lollipop)

In Android 5.0, the entire Android Dalvik runtime was replaced by Android Runtime (ART). As expected, such a major rewrite introduces operating system specific bugs.

Annotations
java.lang.IncompatibleClassChangeError
https://code.google.com/p/android/issues/detail?id=172339

Annotations were rewritten as part of Android 5.0. Even if an Android developer wasn’t directly using Annotations, many popular libraries were hit with the bug including: the Jackson Json processor, FasterXML, Google’s Gson and Guice libraries, Retrofit, and UrbanAirship. This one is tricky because it impacts many parsing and networking libraries that can’t be mitigated simply with a try…catch block.

Android 4.0.x (Ice Cream Sandwich)

java.lang.NoSuchMethodError: android.view.View.setBackground
java.lang.NoSuchMethodError: android.widget.ImageView.setBackground
java.lang.NoSuchMethodError: android.app.Notification$Builder.addAction

Whenever you see “NoSuchMethodError”, your first thought should be to verify your Android minimum SDK version in your build settings. Most likely you are trying to take advantage of new functionality added in a later OS that is unsupported in earlier versions. In the above examples, setBackground() and addAction() were added in API Level 16 (Android 4.1 JellyBean). Be sure you are using an Android support library for backwards compatibility. You can take alternative approaches like checking the Android SDK version at runtime to determine which method you should use.

Which Android OS Versions Should I Support?

Ensuring your app works well on older Android versions is a non-trivial effort. Google has made it easier over the years with the Android Support library and a focus on backwards compatibility built into the Android OS. However, it’s still extra work that is taking time away from feature development. Luckily, we have the data you need to decide how far back to support. The absolute minimum you should support is API Level 19: Android 4.4 (KitKat). This will cover over 91% of Android users. We do not recommend supporting back farther than API Level 16: Android 4.1 (JellyBean). At API Level 16 you are covering ~99% of Android users. Below is a table and graph that displays the Android OS Distributions from a week in July 2016:

Android OS Distribution

Note that this data differs slightly from Google’s dashboard. Our data is based on usage while Google’s data is a bit more representative of installs. We also include data from devices that do not include Google Play Services, like those in China.

For more data on Android device popularity, see our device directory. We also have data on how Android OS usage changes over time as well as Android crash rates.

Topics:
android ,crashes

Published at DZone with permission of Andrew Levy, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}