I am maintaining two android developper tools intent-intercept
and ContentProviderHelper
that declare as many required permessions as possible to work with as many apis (Intents or Contentproviders) as possible.
If i want to use target-api android-6.0 (M) and newer i have to implement an api to ask os/user to grant permission for a certain
api call.
And that is my problem: i donot know in advance which api-call(Intents or Contentproviders) require which permission.
As developper tools the app-s should work with any api.
How can I solve this? Is there a api/lib that tells me which Manifest.permission.XXXX are neccessary to invoke Intents or Contentprovider
or why last call failed?
Do i have to ask for all permissions even if they are not required?
Is there a api/lib that tells me which Manifest.permission.XXXX are neccessary to invoke Intents or Contentprovider
No.
or why last call failed?
Catch the SecurityException, then examine the message of the SecurityException and see if it contains the name of a dangerous permission.
Related
When I try to setup Instabug bug reporting like this:
BugReporting.setInvocationEvents(
InstabugInvocationEvent.SHAKE,
InstabugInvocationEvent.SCREENSHOT
);
The permission request alert is shown. And I don't understand why. Can't Instabug application use environment folders?
As described in documentation:
Generally, the permission request doesn't appear unless the user attempts to use any of the features requiring the permission. The only exception, if you set the invocation event to be Screenshot. Then, the storage permission will be requested when the application launches.
But is there any way to avoid this?
Once again I require your help stackoverflowers!
I've been working on a SDK and now need to verify that the user granted the permissions for stuff like location or file writing.
Verifying is fine, but I think I should ask for the permission if it's needed. The thing is, I have absolutely no access to any activities. I might use the appContext to check for the permissions, but I can't listen to onRequestPermissionsResult like this.
Is there a clever way to ask for permission from my side or should I ask the developers using my SDK to ask the permissions timely so I can use the feature I (and they) need later on?
Thanks for the help!
Personally I'd prefer SDKs to let me as the developer handle when to ask permissions as I may need to give the user some warning, handle it in advance or do other things before prompting them.
If you look at SDKs like Google Play Location services it leaves the handling of the location permissions to the developer and simply adds a warning to the calls that could fail by stating it may throw a SecurityException.
There is also an annotation they use called android.support.annotation.RequiresPermission which you could use to help users of your SDK. Using this annotation will give you the above mentioned Exception warning / error.
Example from official documentation:
#RequiresPermission(anyOf = {Manifest.permission.ACCESS_COARSE_LOCATION, Manifest.permission.ACCESS_FINE_LOCATION})
public abstract Location getLastKnownLocation(String provider);
And as result
I think that you have to declare permissions into documentation and delegate permission-trouble to your sdk users, because library may be part of Model and it mustn't manipulate with UI (permission dialogs)
You can't call permission dialog without activity
I'm using reflection method freeStorageAndNotify:
Method freeStorageAndNotify = null;
freeStorageAndNotify = service.packageManager.getClass().getMethod(
"freeStorageAndNotify", long.class, IPackageDataObserver.class);
freeStorageAndNotify.invoke(PackageManager.class, maxCache + freeSpace, packageDataObserver);
This causes InvocationTargetException:
java.lang.SecurityException: Neither user 10199 nor current process has android.permission.CLEAR_APP_CACHE.
Some points:
- I already have android.permission.CLEAR_APP_CACHE
- This happens only in android "M" Version (Flashed the preview sdk from developer site)
I know this is a hack, and google doesn't bring some official API for that,
But there are so many cleaning apps which cleans all the device cache in one click, so if someone know how to bypass this issue with another workaround i'll be happy to see that.
Thanks very much for the help
There was a bug raised on Android 5 regarding how any app can wipe out all cache files with a regular permission, but cannot wipe out one package's cache files except with a signature-level permission. It's details where
PackageManager has a deleteApplicationCacheFiles() to delete the cache from one package.
This method is hidden from the SDK, and it requires
DELETE_CACHE_FILES, a signature-level permission.
PackageManager also has a freeStorageAndNotify() method, to delete
cache files from all packages. This method is hidden from the SDK, and
it requires the CLEAR_APP_CACHE permission, which is merely flagged
as "dangerous".
It was proposed to either that DELETE_CACHE_FILES should have its level relaxed,
CLEAR_APP_CACHE should have its level raised.
A framework engineer responded
Note that freeStorageAndNotify's purpose is not to wipe out all cache
files, but to free up X amount of space, for example by play store
before it tries to download and install an app. So there are reasons
to use it that work well with the system, but no reason for an app to
use the method that just blindly erases all cache files for a single
app (that is just there for the Settings app UI).
If indeed it is not an app error i.e. you haven't messed up the permissions and it works on Marshmallow / 6 / api 23 and not others that could only mean it became a signature level permission as well, like DELETE_CACHE_FILES.
A signature|system permission, meaning that it can only be held by
apps that are signed with the firmware's signing key or are installed
on the system partition (e.g., by a rooted device user). As described
in this answer.
This would make sense, considering their intended use / their vision (no reason for an app to use the method that just blindly erases all cache files for a single app). It may have even been restricted as a result of that bug. When Android 6's code will come out we will know better (current available is 5.1.1 - link to PackageManager's freeStorageAndNotify).
Refer to these pages: permissions by protection level and protection level definitions.
android.permission.CLEAR_APP_CACHE
This falls under the protection level "signature|privileged" which means that only same-signature or privileged apps (system signed basically) can have this permission.
Also you should check out the Behavior Changes in general.
I've a problem with content provider and custom permissions.
Let's suppose that App A have a content provider containing wonderful informations. These informations are a little bit intrusive, that's why it's better to have a permission to read them.
Let's suppose that App B is a 3rd party application and want to access to the content provider of A.
Let's suppose that the permission to read into the content provider is "com.custom.a.readpermission".
In A manifest, there is :
<permission android:name="com.custom.a.readpermission"/>
<provider android:name="com.a.provider.MyProvider"
android:exported="true"
android:authorities="com.a.provider.MyProvider"
android:readPermission="com.custom.a.readpermission"/>
In B manifest, there is :
<uses-permission android:name="com.custom.a.readpermission"/>
So, now, if I install A; after, I install B. B can access to the data.
But, if I install B before A, I get :
java.lang.SecurityException: Permission Denial: opening provider com.a.provider.MyProvider requires com.custom.a.readpermission
So, how to manage a custom permission in that case ?
So, how to manage a custom permission in that case ?
Your primary options are:
Use a built-in system permission, as opposed to a custom one. This is a good idea in general, if the nature of the sensitive data is similar to other data already defended by built-in permissions.
Catch this exception and tell the user that they need to uninstall A and B and install them in the proper order.
If A and B are both by the same author, use a protectionLevel signature permission and have the same <permission> element in both A and B. Then the installation order will not matter, and the user won't be bothered with any prompts to agree to this permission.
However, bear in mind that prior to Android 5.0, the fact that option #3 works means that any app installed before A could do the same thing as B does, except downgrading the protectionLevel from signature to normal. This is a known vulnerability. Android 5.0 requires that custom permissions are defined on a "first one in wins" basis, and the second and subsequent apps trying to define the same <permission> have to be signed by the same signing key as the app that actually did define it.
In truth, permissions are great for pre-installed apps and the OS itself, but defining custom permissions at the app level is... less than great.
While developing a Launcher (Homescreen) application for Android, I've come into a security exception I don't understand.
When calling the
[bindAppWidgetId()][1] method from
within my Launcher Activity, I get
this security exception :
08-19 11:30:11.689: ERROR/AndroidRuntime(6032): java.lang.SecurityException: bindGagetId appWidgetId=99 provider=ComponentInfo{com.android.music/com.android.music.MediaAppWidgetProvider}: User 10034 does not have android.permission.BIND_APPWIDGET.
I first thought I had forgotten the BIND_APPWIDGET permission in my manifest, but it is definitely there.
The android api documentation states this :
"You need the APPWIDGET_LIST
permission. This method is to be used
by the AppWidget picker."
I tried to add the permission android.permission.APPWIDGET_LIST, but it doesn't solve the issue.
Also, I've looked at the manifest of the Settings application from the android sources that contains the AppWidgetPickActivity code : there's a special line that asks to share user id :
"android:sharedUserId="android.uid.system"
Could it be related to my problem ?
If anyone has an idea that would be great !
Cheers,
Laurent
I've found an answer!
BindAppWidgetId() is deliberately not available to applications! (security problems).
"The android.permission.BIND_APPWIDGET
permission is a system permission. You
can only get that permission if your
package is installed as a system
package (installed in /system/app in
stead of /data/app) or sign you app
with a certificate that's the same as
your android image. So basicly this
means you can only use this permission
if you are also the creator of the
android image on your platform/phone."
Here are the links to this information :
http://groups.google.com/group/android-developers/browse_thread/thread/231245ba6d1e690f/047b9d3f776d7e54?lnk=gst&q=bindAppWidgetId#047b9d3f776d7e54
http://groups.google.com/group/android-developers/browse_thread/thread/f24e0f484a79d529/ef84188e8533a125?lnk=gst&q=bindAppWidgetId#ef84188e8533a125
A quick Google search reveals that android.permission.APPWIDGET_LIST is a usable permission, even though it's not listed in the API docs.