So in my app i would like to add an option to selectively add a permission (say, direct dial) when the user is on Android M but, at the same time, i would like to have that permission NOT showing as required in API 22 or lower simply because its not essential so i prefer not asking for it during install (so de facto making that feature available on M only).
So, i understand the new model of M is that it will allow optional permissions when user is on M and it will make those permissions mandatory when on lower APIs. So is there any known way to just remove those permissions on API lower than 23? Without having separate flavours / APK?
Maybe merging a manifest with just those lines when API is > 22 ? Or there is a cleaner solution?
This is possible. When reading the documentation there is a special flag to indicate for M only.
Use
<uses-permission-sdk23>
to apply permission for Marshmallow devices only.
Related
I am trying to build an app, as a self project, to understand permissions in detail. There are certain permissions, such as 'Bluetooth Connect' that was introduced in Android version 12 (API 31). Now if I am building an app with multiple features, say some of the features were introduced in the first version of Android, but some of them were introduced in the last version, do I have a method to check whether said permission exists in Android? The idea is to remove or restrict those features which are using APIs not defined and still have the app run on all phones.
For example, In my tests, I have noticed the permission when checked, using the ContextCompat.checkSelfPermission method, come back as 'Not granted' for permissions that are supposed to be undefined. Essentially, I want to know if there is a method of knowing whether the permissions are 'undefined'.
Additionally, I have seen some research papers go into the Android system logs and retrieve information. For example - . This is from the paper: Sleeping android: the danger of dormant permissions
I've tried to use ADB logcat to read the log files but not only is it very difficult, it doesn't say anything similar. Am I doing it wrong or was there an update which removed the information?
Even if I can see whether the permission exists or not via logs would be helpful.
Lint is set up to check this for you at compile time. It will force you to check that the SDK version is high enough to check for whichever permission you’re trying to use. For instance, if your minSdkVersion is lower than the version in which a permission constant was introduced, it will be a compile error to use that constant without wrapping it in an if statement that makes sure the SDK version on the device is high enough for it to exist.
I’m not sure how you have defeated this mechanism except that maybe you have compiled the app with Lint disabled.
The paper you linked is absolutely ancient. Lint probably didn’t help you with this back then.
I know we should add "ACCESS_FINE_LOCATION" and "ACCESS_COARSE_LOCATION" permissions and for Android 10 and higher we should add "ACCESS_BACKGROUND_LOCATION".
But if my app is going to be published for all versions starting from android 7 to the latest android 12, how would my AndroidManifest file look like? should I add all the 3 above permissions together?
Adding (even unneccessary) permissions will not lead to crashes or bugs (at least as far as I know), so you can and should add those 3 permissions together, if you want to support that wide range of android versions
I am dealing with an app that has android:sharedUserId value in Manifest,
and there was an issue regarding permission triggered by this android:sharedUserId value.
While trying to solve the problem, I checked out that anderoid:sharedUserId was deprecated in API level 29 (Android 10).
So now I would really like to remove this sharedUserId from the application. (permission problem in API 29 + deprecated in API 29)
As I tested in debug mode, it seems that complete uninstall and reinstall is required after removal of sharedUserId... and It "seems" that there is not much problem else than that.
But I cannot assure that it is really safe to delete this property and release an update on market.
This IssueTracker Thread created in June, 2019 is about this issue, but does not give detailed instruction on how to remove sharedUserId safely from an application.
Would deleting android:sharedUserId without any other modification end up with a critical problem?
If so, does anyone know an appropriate way to remove sharedUserId from Manifest file and safely release an update version?
OK, I just checked out the documentation again in original English version... and found out this sentence was omitted in Korean translation.
Note that existing apps cannot remove this value, as migrating off a
shared user ID is not supported.
So sharedUserId drives out problems in Android 10 (obviously in my case), and there is no way to remove it. Did I get it right?
If so... well... I find this very surprising... and disappointing...
This wasn't possible, but Android introduced a solution for this in sdk 33. It's called the android:sharedUserMaxSdkVersion attribute. It's only available in android 13. The documentation says:
The maximum device SDK version for which the application will remain in the user ID defined in sharedUserId. Used when the application wants to migrate out of using shared user ID, but has to maintain backwards compatibility with the API level specified and before.
So I think you should define: android:sharedUserMaxSdkVersion="29". But I'm not completely sure yet how this option should be interpreted.
Im using WebRTC with cordova and I made the huge mistake of upgrading the version of android in the play store from 22 to 23. (apparently no way to revert this situation)
Now I must ask for the permissions at runtime. Everything is ok for now, but for WebRTC communication my app needs this particular permission "MODIFY_AUDIO_SETTINGS". For camera, microphone and location permissions I use cordova-diagnostic-plugin using those methods : requestCameraAuthorization, requestMicrophoneAuthorization and requestLocationAuthorization.
I tried requestRuntimePermission method with this as argument cordova.plugins.diagnostic.permission.MODIFY_AUDIO_SETTINGS but its not working since cordova.plugins.diagnostic.permission doesnt contain 'MODIFY_AUDIO_SETTINGS' permission. Here is the list of available permissions :
Im pretty much sur that the problem is the lack of 'MODIFY_AUDIO_SETTINGS' permission, since I had the same problem with android 22 (no audio) because I was not including it in the config. see this old SO post of mine
Thanks.
MODIFY_AUDIO_SETTINGS is not a "dangerous" permission that can be requested at run-time on Android: see here the full list of "dangerous" permissions which need to be requested at run-time.
I wrote a program that worked perfectly until the market required me to add 'minSdkVersion'. Since I was using 2.3.3 capabilities I set it at 10,but then my program stopped being able to access files from the disk (all file access is false though it works without 'minSdkVersion'). Changing it to require API 1 fixed the functionality but now inadequate OS versions can download it. Should the 'minSdkVersion' be able to change actual functionality? Any ideas what could cause this?
You should set minSdkVersion to the lowest adequate OS version for your app. Don't forget to also set targetSdkVersion to the highest level for which your app has been tested.
I'm going to assume when you say "access files" you mean on the SD card.
In this case, you need to add 2 new permissions:
<uses-permission
android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission
android:name="android.permission.READ_EXTERNAL_STORAGE"/>
These permissions weren't added until API level 4, so anything below that gets them for free.