I'm developing an Android library which provides ways to reach into various system services and gather data for analysis. My classes make use of various system service managers (like WifiManager
) to gather the data.
I'd like to structure the manifest of my library such that it doesn't grab all the possible permissions that all of these features require. Instead, I'd like to leave it up to the app consuming that library to declare only the permissions that it will need, which might be a smaller subset of what's used by the library.
This actually works in practice, because the manifests all get merged together during the build process, so the app ends up with the permissions it needs to use the features of the library. However, since the <uses-permission>
tag isn't in the library's manifest, the code is all lit up with warnings from Android Studio.
Is there a way to annotate my library code such that the permission check is ignored?
Of course I can simply turn off the "Constant and Resource Type Mismatches" inspection in my Android Studio settings, but that won't help anyone else who's trying to use the library. I tried finding a reference to this inspection in the documentation (so I could kill it with @SuppressWarnings
but haven't found it yet.
Is this even a worthwhile approach?
…or should I, instead, have the library grab all the permissions it needs, which would force a consumer of the library to turn off the ones it doesn't need using the tools:node="remove"
property in its manifest? The problem here is that, as I add features to my library, my library's consumers would repeatedly have to circle back and explicitly remove those new permissions as well. I feel like that's not a great model and I'd rather leave the permission requests to my consumers.
Consider the following conversations on the subject —
In just randomly right-clicking around the issue I was able to choose the Suppress for method context command in Android Studio and it added the following annotation:
@SuppressWarnings( "ResourceType" )
So… yay! There's the answer to which annotation to use.
I'm still interested, though, in what people's thoughts are regarding the approach in general. Please feel free to hash that out in the answers section. ^_^