Manifest Merger, maxSdkVersion, and a Missing Permission

Manifest merger is a wonderful thing in Android app development… usually. It allows libraries to contribute elements and attributes automatically to an app’s manifest, saving the app developer from adding those things manually.

However, sometimes, it will not work in an intuitive fashion.

Such appears to have been the case for a developer, who posted this Stack Overflow question, outlining some curious symptoms. Despite having a <uses-permission> element for WRITE_EXTERNAL_STORAGE , when he would request it at runtime, he would never get it. In fact, if he did not also ask for READ_EXTERNAL_STORAGE , Android would not even bother asking the user about the runtime permission.

This symptom – calling requestPermissions() and being rejected outright – sometimes is caused by the user having clicked “Don’t ask again” for the permission. However, it can also occur if your manifest lacks the <uses-permission> element… but that did not appear to be the case here.

Until the developer checked the merged manifest.

Something – I assume a library – was adding android:maxSdkVersion="18" to WRITE_EXTERNAL_STORAGE . Presumably, the library is writing to getExternalFilesDir() and needs this permission on older devices, but not newer ones. However, the app needed the permission for all versions, as the app is writing elsewhere on external storage. maxSdkVersion causes the <uses-permission> element to vanish, in effect, on newer devices. That’s why runtime permissions were not working. Even though the app had the <uses-permission> element, the library’s contributed maxSdkVersion negated it for newer devices.

The fix for the app developer was to add tools:remove="android:maxSdkVersion" to that <uses-permission> element, to block the maxSdkVersion attribute and allow the permission to be requested on all devices.

From the standpoint of the library author, though, this is a case of “being caught between a rock and a hard place”. If you include maxSdkVersion , you correctly advertise your library’s needs and you minimize the permissions that your library contributes to the app. However, for dangerous permissions, it violates the Principle of Least “WTF?” for app developers using the library. If you do not include maxSdkVersion , you cause fewer problems for app developers who need the permission all the time, but you may wind up requiring the permission in cases where it is not needed.

My guess is that WRITE_EXTERNAL_STORAGE is the #1 permission for use with maxSdkVersion . If your library requests this permission, think about whether maxSdkVersion is appropriate for your use case… and then document your requirements. In particular, if you use maxSdkVersion , make sure that your documentation mentions this and prompts library users to add deal with this if their apps require the permission for more API levels.

Developers using libraries should peer at the Merged Manifest tab of Android Studio from time to time, to see what’s in there and tailor the results via tools: attributes as needed.

With a bit two tons of luck, we might get more information when this occurs in LogCat.

Nervous about how the newest version of Android affects your app? Consider subscribing, then asking questions in the office hours chats!

— Apr 09, 2018