Migrating Apps to Android 6.0 Marshmallow
A client of ours is planning to release a new version of their Android app soon, so we’ve started to test it for compatibility with the newly-released Android 6.0 “Marshmallow” (sdk 23).
We found two problems – one that we expected, and one that we did not.
Runtime Permissions
The problem that we expected was with Marshmallow’s new Runtime Permissions.
Up through Lollipop (sdk 22), the permission model is simple.
You just list the permissions that the app requires in the AndroidManifest.xml, and the user is shown this list at installation time. The typical user doesn’t read the list of permissions, just accepts them (“whatever…”), and installs the app. Your app is now automatically granted all of the permissions listed in the manifest, and the user never has to think about it again.
“Danger, Will Robinson…”
Starting with Marshmallow (sdk 23), permissions are categorized as either “normal” or “dangerous”. Normal permissions include things like accessing the internet. Dangerous permissions include things like reading from and writing to the contacts, and reading from and writing to external storage.
See the Android Developer website for the full list.
You still need to list both “normal” and “dangerous” permissions in the manifest, and “normal” permissions are still granted automatically. However, for “dangerous” permissions, the application must check for permission at runtime each time before it attempts to do something that requires that permission.
This is because the user must give permission the first time, and may decide to revoke the permission at any time without the app’s knowledge. Attempting to take an action requiring a “dangerous” permission without actually having the permission will throw an exception, and likely crash your application.
Having to ask for permission also means that your application must be prepared to handle a situation where a permission is denied. Typically, this would mean disabling a feature. In our case, for instance, we have a feature that requires the user to supply a friend’s contact information. They can choose a contact from the phone’s contact list, or fill out a form. If permission to read the contacts is denied, we would have to disable the option to choose a contact, and only present the user with the form.
It’s going to take us some time to go through the app, identify all of the situations where we use a feature that requires a “dangerous” permission, handle each situation, and test it all.
Fortunately, a close read of the documentation indicated that for backward compatibility, applications built for earlier sdk versions will continue to operate under the old permission model, with all permissions being granted at installation time. It turns out that all you need to do is change the value of the targetSdkVersion to 22 in the build.gradle file.
We are using compileSdkVersion 23 and buildToolsVersion "23.0.1", as well as 23.x versions of the appCompat and support libraries, and have found that everything still works fine on both skd 23 and older versions after switching the targetSdkVersion from 23 to 22.
We’ll switch back to targetSdkVersion 23 after we’ve resolved the issues, and do a point-release.
Conceal Crypto Library (and others?)
The unexpected problem was with the crypto library that we’re using. FaceBook’s Conceal library is a very easy-to-use crypto library, and has the distinction of being one of the few that both gets crypto right, and works on virtually all modern versions of Android.
It’s also very fast, dramatically faster as compared to the Java/Android – provided crypto libraries, the now-infamous Bouncycastle libraries, and, I’m guessing, the BouncyCastle fork, “SpongyCastle”.
Much of this speed boost comes from a native-library implementation. The problem is apparently that Conceal’s native library, libconceal.so, was either built with a compiler version that has some issues, or one if it’s statically linked libraries was. For more detailed info, see StackOverflow.
It looks like this problem (text relocations in the native library) wasn’t an issue for previous versions of Android. Fortunately, as with the Permissions issue, setting the Android application’s targetSdkVersion to 22 is a viable workaround.
So, once Facebook recompiles their native library to remove the text relocations, and we implement Runtime Permission checking, we should be ready to move up to targetSdk 23, but in the short-term, we’ll be able to release without waiting to fix those issues.