In Android documentation on permission-tree, I cannot find any use scenario showing permission-tree is useful.
Now there are several questions in my mind:
Why do we need permission-tree?
Is there any real scenario to illustrate permission-tree is necessary?
Is there any example to demonstrate how the client App requests the permission-tree?
Why do we need permission-tree?
When you use permission-tree, you don't want other apps to use any permission with the same base name as you declared from permission-tree.
For example, you use
<permission-tree
android:name="com.example.project.taxes"
android:label="" />
Which means you don't want other apps to use any permission prefix with "com.example.project.taxes".
If there is any app with the same base name installed before your app, both apps' permissions are valid.
If your app installed first, and another app using a permission prefix with your base name, another app's protection level will automatically change to "signature", even it declares as "normal" in the AndroidManifest.xml.
This can be checked when you pull system packages file from devices.
adb pull /data/system/packages.xml
Normal permission is like this,
<item name="com.google.android.gms.permission.TRANSFER_WIFI_CREDENTIAL" package="com.google.android.gms" />
If there is a conflict, it will become like this.
<item name="com.google.android.gms.permission.TRANSFER_WIFI_CREDENTIAL" package="com.google.android.gms" protection="2" />
That means you will block all the future installed app to gain the normal permission with your base name.
When some app trying to use it, Logcat will log some message like this when the app is installing,
PackageManager: Un-granting permission com.example.project.taxes.deductions.MAKE_SOME_UP from package com.others.app
So be careful to choose your permission-tree name.
Is there any real scenario to illustrate permission-tree is necessary?
From the /data/system/packages.xml from a new device, I can see only a google app is using permission tree.
<permission-trees>
<item name="com.google.android.googleapps.permission.GOOGLE_AUTH" package="com.google.android.gsf" />
</permission-trees>
And this app really uses a lot of customised permission, that's why it needs to declared the permission tree and not allow others to conflict with them.
Is there any example to demonstrate how the client App requests the permission-tree?
This is example how client app request the permission tree.
<permission-tree
android:name="com.example.project.taxes"
android:label="" />
But I don't think a client app is necessary to use permission tree, it's more meaningful for a system app. Otherwise, use a long name for permission tree, make sure no one else has conflict with this name.
Related
(if you came here by googling looking for a solution for this error,below links will give you an answer,also my question has kind of an explanation!)
Possible duplicate of
INSTALL_FAILED_DUPLICATE_PERMISSION… C2D_MESSAGE
Error -505 INSTALL_FAILED_DUPLICATE_PERMISSION
Wait!
I got this error today in a live project.User came with the 505 error unable to install the app.Then i ran it on IDE!
If you download an app with this mentioned issue from play store you will get an error with 505 when you try to install.
If you try to run it using your IDE you will get the error like in above image! (correct me if I am wrong)
Then I was looking for reasons.
This was my issue!
<permission
android:name="in.wptrafficanalyzer.locationroutedirectionmapv2.permission.MAPS_RECEIVE"
android:protectionLevel="signature" />
<uses-permission android:name="in.wptrafficanalyzer.locationroutedirectionmapv2.permission.MAPS_RECEIVE" />
Surprise thing was another developer's app on a particular users phone used the same signature! Damn, those copy pastes met each other today!!
I think if I try to declare same permission in two applications with
same package name this error can occur.(correct me if I am wrong)
Here are my 2 questions?
1.Do they need to be with the same permission? anyway they will get this thing when its same. lets say app A users a pkg.name with permission permission.RECEIVE app B use same package with another permission CONFIGURE_SIP.Can this occur when they meet each other?(seems like a stupid question but I want to confirm the other app that was there in the client's mobile had the same thing!)
2.What are/is there any other the possibilities that this error can occur?
An application defines a custom permission using signature level security
You attempt to update the installed app with a version signed with a different key
The test device is running Android 21 or newer with support for multiple users
Got those 1 2 3 from this post ! Are they true? If yes any good explanation about them will be great or any additional reason for this error?
There are many good answers in the mentioned posts!Not asking how to fix this! But how it gets generated! Also if I mentioned/understood something wrong please do note it down!!
Thank you.
Edit : As I mentioned please note that the issue came form an app which is already in the Play Store. And about the other app I have no idea! It's there in the client's mobile.Probably its also from play store because even developer options was not activated till I try to run on that mobile.He did not had any previous apps from my company as well.He just tried to download the app got 505 error and came to fix it.
And also my first option was the removal of that permission an it made the app install successfully(not the right thing but to confirm where the issue was). That is the reason that I need to know the possibilities of this error!
#commonsware blogs has explain it in details in Custom Permission Vulnerability and the 'L' Developer Preview:
Near as I can tell, the “L” Developer Preview requires that all apps
with a <permission> element for the same android:name value be signed
by the same signing key. The actual protectionLevel or other values
inside the <permission> does not matter. Even if they are identical, an
app trying to define the <permission> will fail to install if an
existing installed app already defines the <permission>. Specifically,
the installation of the second app will fail with an
INSTALL_FAILED_DUPLICATE_PERMISSION error.
Here the answer from #commonsware: https://stackoverflow.com/a/11730133/4758255
Your problem isn't permissions. It's impossible to have two apps with the same manifest package name.It must be unique. So system think that user try to reinstall/update old app with new signing certificate. From android developers blog
If the signing certificate changes, trying to install the new application on to the device will fail until the old version is uninstalled.
EDIT:
I run some tests with permissions. I think, behavior is very similar with application package name. Error occur only if 100% matching. Results:
app A(package test.test) vs app B(package test.test2)
package="test.test">
<permission
android:name="test2.example.h"
android:protectionLevel="signature" />
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="test.test2">
<permission
android:name="test.example.hr"
android:protectionLevel="signature" />
permission A - test.example.h vs B - test.example.h - DUPLICATE_PERMSSIONS error
test.example vs test.example.h - success
test.example.g vs test.example.h - success
uses-permission doesn't affect on errors/installations. But I think you can get SeciurityException in runtime, if try to use others permissions.
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.
I have two apps. one of the two has a custom content provider which works like a charm.
APP A -> The one with the provider
APP B -> The one that needs the data from the provider
Everything works fine in this scenario:
1st : Install app A
2nd: Install app B
However when I do it like this:
1st: Install app B
2nd: Install app A
I get the error :
09-19 13:07:22.576: E/AndroidRuntime(14621): Caused by: java.lang.SecurityException: Permission Denial: opening provider
uk.co.ringsizer.ui.BirthProvider from ProcessRecord{450c14c8 14621:uk.co.gemtv/u0a360}
(pid=14621, uid=10360) requires com.eir.provider.Size.READ_DATABASE
or com.eir.provider.Size.WRITE_DATABASE
My permissions are clearly stated in the manifest file and they are correct since it works if I install the apps in a different order.
It's the first time I'm using Content provider and I am relatively new to Android so the problem might be obvious to more experienced developers.
Any ideas? Has anybody else experienced the same issue before?
Thanks in advance.
The app that defines the custom <permission> must be installed before the app that requests it via <uses-permission>. If they are installed in the wrong order, the <uses-permission> app does not get the permission and must be uninstalled and reinstalled.
Custom permissions in general are risky for SDK apps.
Make sure that BOTH apps have the permission attribute in the manifest.
<permission android:name="com.example.permission.READ" />
I had only the use-permission attribute in the consuming app, and had exactly this problem. It'll work if the content provider app is installed first, but will fail if the content provider app is installed second.
When the consuming client app has the permission attribute as well, it will work regardless of app install order.
I am inheriting a code base that needs to be kept fairly in sync with the previous version to make updating to new versions as painless as possible when they push the changes via git. The changes I am making are related to re-styling and adding new features.
In the latest release, I was trying to install both the original version of the app alongside this custom version and got this error:
Failure [INSTALL_FAILED_CONFLICTING_PROVIDER]
I looked through my source control and found that in previous versions I was using the same authorities and name as the parent app, but I don't recall having this problem, but maybe I just never tested the case where both apps were installed at the same time?
In the original version of the manifest, this is the provider element:
<provider
android:name="com.foo.mobile.android.provider.Provider"
android:authorities="com.foo.android.mobile.contentprovider"
android:exported="false" />
I tried changing the authority to this:
<provider
android:name="com.foo.mobile.android.provider.Provider"
android:authorities="com.bar.android.mobile.contentprovider"
android:exported="false" />
But now the app crashes shortly after launch with SecurityException:
java.lang.SecurityException: Permission Denial: opening provider com.foo.mobile.android.provider.Provider from ProcessRecord{42cbc998 2462:com.bar/u0a191} (pid=2462, uid=10191) that is not exported from uid 10189
I've looked on SO and saw a couple of questions regarding this topic and also looked at the documentation and it all says I need this authorities to be different, but how can I keep this different while keeping synergy with the base code?
maybe I just never tested the case where both apps were installed at the same time?
I would presume this is the case. You cannot have two apps with providers supporting the same authority installed at the same time.
But now the app crashes shortly after launch with SecurityException:
My guess is that you changed your manifest, but you did not change the Uri that you are using to access the provider. Hence, your com.bar app is still trying to talk to the com.foo provider, and that provider is not exported.
how can I keep this different while keeping synergy with the base code?
Either this is the same app, or it is not.
If it is the same app, your first step is to switch back to the original package name. The only way you could have gotten Failure [INSTALL_FAILED_CONFLICTING_PROVIDER] is because you changed the package name and did not change the provider's authority. Changing the package name means that, from the standpoint of everyone outside of you and your team, it is a completely different app. Once you have switched back to the original package name (and rolled back to the original provider authority), everything should be fine, except that you won't be able to have the release version and the development version on the same device at the same time.
If you do indeed plan to have this app have a separate package name (so existing users of the existing app cannot upgrade to this new app), you will need to change the authority string in all relevant places. I presume that you can do this using a string resource, where you have different versions of the string resource. Or, if this is a free-vs.-paid app scenario, move to doing your builds using Gradle for Android, and set up separate free and paid product flavors, which can patch up your package name and authority data as part of the builds, without having to tweak the source code.
This is my first time posting here. I'm not sure if this is the right place to ask this question, but I don't seem to find other more appropriate places. Here's my question anyways.
I understand that the API ActivityManager.forceStopPackage() is an internal one and can be called only from system process. However, it puzzles me that the built-in Task Manager app (with package name com.motorola.PerformanceManager) on my motorola atrix phone can directly call it without being a system process. There are two things that I verified.
First, it is non-system process from ps command:
app_64 13681 1379 170788 29820 ffffffff 00000000 S com.motorola.PerformanceManager
Second, it indeed calls the ActivityManager.forceStopPackage() API from its odex file (decompiled into smali, then into dex, and then into java). From the smali code, it is already clear that it calls this API.
I also checked its AndroidManifest.xml file which seems nothing special to me (the forum mistakenly recognizes the content as URLs and prevents me from posting them).
The manifest file does include the android.permission.FORCE_STOP_PACKAGES permission which is supposed to be a system one. A non-system app will still get permission denial error even with this permission. I tried using reflection to access this API with android.permission.FORCE_STOP_PACKAGES permission but still get the runtime error.
Now, how can the built-in Task Manager app call the internal API without being a system process.
One possibility is that the app is signed with the same platform private key. However, I'm not sure how I can verify that. Further, it is still supposed to be a system process with additional descriptions in the manifest file.
Hope someone can answer my question. Thanks.
The "android.permission.FORCE_STOP_PACKAGES" permission is protected by the platform signature.
If you have Android source code then check the declaration of the permission:
/frameworks/base/core/res/AndroidManifest.xml
...
<permission android:name="android.permission.FORCE_STOP_PACKAGES"
android:permissionGroup="android.permission-group.SYSTEM_TOOLS"
android:protectionLevel="signature"
...
You can see its protection level is signature, then check the SDK documentation for the explaination:
"android:protectionLevel"
http://developer.android.com/guide/topics/manifest/permission-element.html#plevel
"signature...A permission that the system grants only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user's explicit approval"
The permission is declared by the framework-res which is signed by the platform signature, so the application that wants to use the permission shall also be signed with the same signature.
/frameworks/base/core/res/Android.mk
...
LOCAL_PACKAGE_NAME := framework-res
LOCAL_CERTIFICATE := platform
...
Regards
Ziteng Chen