I have a function in a custom library that requires the BLUETOOTH_SCAN and BLUETOOTH_CONNECT permissions. Starting with Android 12, I can't just rely on adding them to the manifest XML - runtime checks are also required then.
I added the RequiresPermission annotation to my function, like this:
#RequiresPermission(allOf = [Manifest.permission.BLUETOOTH_SCAN, Manifest.permission.BLUETOOTH_CONNECT])
fun myFunction()
However, I get this warning:
Field requires API level 31 (current min is 28): android.Manifest.permission#BLUETOOTH_SCAN
I set the min SDK version to 28 on purpose. But now I am stuck. for Android 12 and newer, I need the annotation to emphasize that callers check for those permissions (in other words, I want there to be a warning if callers use my function without a permission check). for Android 11 and older, the annotation must not be present? How do I solve this? I know that RequiresPermission has a conditional argument, but I do not know how to use this for this purpose. I tried to instead use BLUETOOTH and BLUETOOTH_ADMIN permissions in the annotation, but Android Studio still complains that the Bluetooth APIs that are internally used in the function need to be surrounded by permission checks.
You could annotate android version like the following (for example only, this is a different permission request)
#RequiresApi(api = Build.VERSION_CODES.TIRAMISU)
#RequiresPermission(allOf = {Manifest.permission.POST_NOTIFICATIONS})
Although I find it easier to read and debug later by having all versions call the request permission function then return early if the version is too low
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.TIRAMISU) {
return
}
//continue to ask for permission
Related
I am trying to solve for issues around TelephonyManager and add compatibility for listening to phone call state for Android 12 and above. My app has targetSdkVersion set to 31. If I try to register the telephony callbacks in onCreate, Android Studio applies the annotation #RequiresApi(api = Build.VERSION_CODES.S) to it. I've gone through the documentation for the requiresApi and it seems to suggest that this function will be called if the user is running Android 12 and above.
Is my understanding correct?
I have encapsulated permission check into utility method and now I am receiving
Call requires permission which may be rejected by user: code should
explicitly check to see if permission is available (with
checkPermission) or explicitly handle a potential
SecurityException
error.
Like this:
Is it possible to smart control this error, for example, by adding some annotation (not just completely disable checking)?
Is it possible to smart control this error
This is not error per se but warning generated by static code analyser, most likely by bundled Lint. If that is so, you can suppress it by using #SuppressWarnings() annotation. See official docs on that: Suppressing Lint Warnings
I'm using Android Studio 1.3.2 on win7(64-bit) machine, developing application with kitkat (API level 23).
I'm trying to set brightness using seekbar control and have mentioned permission in manifest file as below
<uses-permission android:name="android.permission.WRITE_SETTINGS" />
Now i'm getting the below exception
java.lang.SecurityException: com.sam.shmiandan.androidbrightness was not granted this permission: android.permission.WRITE_SETTINGS
How can I solve below error ?
**
Note : You are using API 23 level which is not Kitkat.
**
To use WRITE_SETTINGS, based on the docs:
Have the element in the manifest as normal..
Call Settings.System.canWrite() to see if you are eligible to write out settings.
If canWrite() returns false, start up the ACTION_MANAGE_WRITE_SETTINGS activity so the user can agree there to allow your app to actually write to settings.
IOW, writing to settings is now a double-opt-in (agree to install, agree separately in Settings to allow), akin to device admin APIs, accessibility services, etc.
Also note that I have not tried using these yet — this is based on research that I did yesterday on Android 6.0 changes
Reference : Can't get WRITE_SETTINGS permission
I'm trying to access the Usage_Stats_Service in lollipop through this :
final UsageStatsManager usageStatsManager=(UsageStatsManager)this.getSystemService(Context.USAGE_STATS_SERVICE);
I can go to the Context class and see how this constant exist but Android Studio keeps saying that it is not a valid constant.
I have tried to use the literal string too but it seems getSystemService has a constraint to only accept #ServiceName constants.
I have spent almost 2 hours into this without finding out what is hapenning. Any help is welcomed.
Android Studio keeps saying that it is not a valid constant.
It isn't a publicly available constant because USAGE_STAT_SERVICE is hidden using the #hide annotation in the source code. This is supported by the lack of USAGE_STAT_SERVICE in the documentation.
getSystemService has a constraint to only accept #ServiceName
constants.
This is due to "attribute inspection" and should not affect compilation. It can be turned off.
I've also successfully gotten an instance of UsageManagerService using a direct string.
UsageStatsManager manager = (UsageStatsManager) getSystemService("usagestats");
Additionally, it is worth noting that the permission required,
android.permission.PACKAGE_USAGE_STATS
is simply flagged by Studio as a permission that can't be granted (technically true based on the documentation) so Studio at this time, does not know about "special" permissions such as these.
Usage Access can be granted in
Settings > Security > Apps with usage access
My android app has nothing to do with phone calls, but I'm seeing that when I install a debug build on my test device it requires "Phone Calls: read phone state and identity" permissions. (I make no mention of this in AndroidManifest.xml).
I'd like to have the minimum possible permissions, and wondered if anyone knew how to get rid of this? I commented out the part where I was logging some stuff from Build.MODEL, Build.VERSION.*, etc. I also commented out the part where I was detecting the landscape/portrait orientation thinking that that might be the "phone state". But neither of those seemed to remove that permission required.
I found this bug report: http://code.google.com/p/android/issues/detail?id=4101 but it's marked working-as-intended with a note about permissions being correct from the market but not otherwise. Is this other people's experience? (I'd hate to have to publish to the market just to test that out.) Otherwise, does anyone know if there's an API I can avoid calling that will make it so my app doesn't need this permission?
Thanks!
(Answering my own question in case anyone else runs into this problem and searches for it.)
Digging around in PackageParser.java in the android source, I found out that the system will automatically assign
android.permission.WRITE_EXTERNAL_STORAGE and
android.permission.READ_PHONE_STATE
to any app that declares a targetSdk version of less than 4 (donut). There must be a compatibility reason for this, maybe apps targeting older versions could assume they had these permissions without declaring them explicitly. So, if you don't want these permissions added to your app implicitly, add a section like the following in AndroidManifest.xml
<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="4" />
That is all.
Have fun, -Mike
Android 1.6 changelog: http://developer.android.com/sdk/android-1.6.html#api
WRITE_EXTERNAL_STORAGE: Allows an
application to write to external
storage. Applications using API Level
3 and lower will be implicitly granted
this permission (and this will be
visible to the user); Applications
using API Level 4 or higher must
explicitly request this permission.
But that is only one of them. For some reason the official change log is missing the info about READ_PHONE_STATE. The full story is cleared up here: http://blogs.zdnet.com/Burnette/?p=1369&page=3
New permissions. 1.6 programs must
explicitly request the
WRITE_EXTERNAL_STORAGE permission to
be able to modify the contents of the
SD card, and they must explicitly
request the READ_PHONE_STATE
permission to be able to be able to
retrieve phone state info. Apps
targeting earlier versions will always
request these permissions implicitly.
So as you can see, there is no way to publish an app targeted at 1.5 or earlier without requesting those permissions when installed on phones running 1.6 or higher.