Seems like getDrawable() of WallpaperManager is useless on Android 13 since users can't get READ_EXTERNAL_STORAGE permission for it.
Is there any way to get current wallpaper on API level 33? I mean without lowering targetSdk level, etc.
For my tiny live wallpaper app (here), I offer to import previous wallpaper, so I need this too. I also need a similar function getWallpaperFile which also needs storage permission.
Currently the only workaround I've found is to use MANAGE_EXTERNAL_STORAGE permission.
However, when I tried to publish my app with this permission, the policy team rejected it. I'm trying to send an appeal after an appeal, and so far it doesn't help.
I hope Google will solve it, or I will have to prepare an app that this is its whole purpose, as a companion to my own app.
You could target API 32 , before this change, but of course this won't be an option when Google will force developers to target API 33...
I also tried to reach the files themselves ( they are on "/data/system/users/0" , named "wallpaper" and "wallpaper_lock"), but sadly I failed to read them without the permission I've mentioned. I could do it with root access, but that's not the same at all...
Because of these terrible changes on Android 13, I've created a new request to have a new permission just to get the current wallpaper information (be it an image from lock/home or a live wallpaper ), here:
https://issuetracker.google.com/issues/263721379
Please consider starring.
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'm trying to compile Python code directly on my Android phone via QPython 3L and it's fine for some initial examples.
Now I want to read the call log and here is my code.
from androidhelper import sl4a
droid = sl4a.Android()
myconst = droid.getConstants("android.provider.CallLog$Calls").result
print(myconst['CONTENT_URI'])
calls=droid.queryContent(myconst['CONTENT_URI'],["number","duration","date","type"]).result
At the last line above it throws a NullPointerException and - after many trials&errors and searches on Google - I'm pretty sure that the root cause is a lack of authorization.
Can you confirm if this is the case (or you spot a bug, contrary to what I believe) and please point me to some documentation, for adding the authorization request, if that is appropriate to my specific code context?
Sometimes to solve programming issues like this, one needs luck, a lot of fantasy and an extreme willpower.
The solution (once one really knows what to do and where to search) can be found on this github page.
The FAQ reads:
A: Why are there so many branches? Q: Because Google Play and some
appstores have strict requirements for application permissions, they
require different permissions, we use different branch codes, for
example, 3 means it is QPython3, L means LIMITED, S means SENSITIVE
permission is required.
After a special (one-off) installation via download on Android, you have to manually add the Telephone permission to the application, using Android permission management. The downloaded app will replace the one installed via Google Play and you'll find your script already there, ready to be run, hopefully without the NPE.
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 set my gradle for min API 18 and Tagret API23.
I use the new permission system as need for API23 and also write all the require permission in the manifest as in the old days.
On Device use API23 it is work O.K.
But when I put the APK on device with 5.1.1 also it show me all the require permission during installation and i accept it, it is look that it doesn't get them in the application itself.
I also check in the application setting of this APK on the device and see all the permission are there (there is no checkbox so I assume if it is written it is enable).
Does the new permission system together with the old way (permission in manifest ) has to addapt automaticly to the device API level, or I need to make any check during the application runtime?
I figure it out by myself. For install the new APK I have to remove the older one completely. If I just go to the setting->Application found the app and delete it by “remove completely” it is not enough. I have to go to the actionBar on top in the same window and by the 3 buttons ask to “remove for all users”. Only then it doesn't have any trace and when I install the new APK it gets the right permission automatically.
Is it possible at application level? Or do we have to do it inside the OS?
People might want to do this to reduce the attack surface. Ideally, the application, at virtually any point of time, should have a permission only if it is needed, following the `principle of least privilege'.
To clarify: by "change", I mean to give up certain permissions temporarily, and regain them sometime later when they are really needed.
Is it possible at application level? Or do we have to do it inside the OS?
You cannot change the permissions of your application dynamically, ever.
It would be against clarity Android policys . The application has or not has the permisions for doing something . It can be a security problem if you can think of it.
Officially this is not supported.
Newer CyanogenMod builds support "revoked permissions", but applications often force close if they lose permission they were supposed to have.