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
Related
I am trying to create a new release of my Codename One app for Android. When I upload the APK to the Google Play Console, I get an error that my APK uses android.permission.READ_PHONE_STATE and that I do need a privacy policy to be able to use that permission.
In the Codename One blog I read:
android.permission.READ_PHONE_STATE - is triggered by com.codename1.ads package, com.codename1.components.Ads, com.codename1.components.ShareButton, com.codename1.media, com.codename1.push, Display.getUdid() & Display.getMsisdn(). This permission is required for media in order to suspend audio playback when you get a phone call.
But my app does not use ads, does not use sharing, does not use media, does not use push and does not use UDID nor MSISDN. Hence, I have no clue why I would need this permission (which indeed is present in the generated APK).
How can I prevent this permission being added to the APK (or how can I detect why this permission is added).
#
#Sat Sep 28 17:12:49 BST 2019
codename1.vendor=Frans van Gool
codename1.displayName=S\u00F3 Verbos
codename1.icon=/C\:/EclipseData/JustVerbs/GaloDeBarcelos.png
codename1.arg.java.version=8
codename1.languageLevel=5
codename1.secondaryTitle=S\u00F3 Verbos
codename1.version=1.20
codename1.mainName=Main
codename1.ios.certificatePassword=
codename1.arg.ios.newStorageLocation=true
codename1.rim.signtoolDb=
libVersion=212
codename1.ios.certificate=
codename1.android.keystorePassword=**************
codename1.j2me.nativeTheme=nativej2me.res
codename1.rim.signtoolCsk=
codename1.android.keystore=/C\:/eclipseData/JustVerbs/keychain.ks
codename1.android.keystoreAlias=justverbs
codename1.rim.certificatePassword=
codename1.ios.provision=
codename1.packageName=nl.griffelservices.justverbs
Apparently this works (this text has always been here - not sure why it was hidden)
<uses-permission tools:node="remove" android:name="android.permission.READ_PHONE_STATE" />
<uses-permission tools:node="remove" android:name="android.permission.READ_PHONE_STATE" />
see:
https://facebook.github.io/react-native/docs/removing-default-permissions
(apparently this link no longer works)
I have implemented it but have not tried it (many moons later - I have tried it and it does work). I did not know one could remove permissions in the manifest - first of all I never expected they would get added!
I searched through my Flutter project, also the plugin directories and tried to find out where the required Android permissions are coming from.
I only found the permission for internet access, which is required by default, in the manifest file of my application:
<uses-permission android:name="android.permission.INTERNET"/>
However, the following permissions are listed as well when installing the application:
view network connections
full network access
prevent device from
sleeping
These are considered as normal permissions, but still I would like to find out where they are coming from because the application does not need these, I believe.
The manifest you see in your source is not the one that's in the final APK. The final AndroidManifest gets built up through the build process and compiled from different sources. If you'd like to see a full report of the manifest merging you can go into
build/app/outputs/logs
This is a very long log report, but you can read where all the manifest parts are coming from. If you'd like to see the final manifest itself this can be found in
build/app/intermediates/manifests/full/release or
build/app/intermediates/manifests/full/debug
This won't let you know where it's from, but you can look at the permissions and do a search in your build folder and you should find the partial manifest generated somewhere and you can see where exactly it's coming from.
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.
Been doing some Android permission research and ran across an application that - according to the AndroidManifest.xml file - only declares WRITE_EXTERNAL_STORAGE as a permission. The Android Market only reports this as well. Using the aapt tool to dump the uses-permission it also only reports the one permission.
However, in code running on the Android device (or emulator), doing the following:
PackageManager pm = getPackageManager();
List<PackageInfo> pkgList = pm.getInstalledPackages(PackageManager.GET_PERMISSIONS | PackageManager.GET_SIGNATURES);
...
PackageInfo p = pkgList.get(i); // where i is the index of the apk in question
String[] perms = p.requestedPermissions;
I get 2 permissions for this APK, READ_PHONE_STATE and the one in the manifest, WRITE_EXTERNAL_STORAGE. Looking at the "Manage Apps" screen and selecting details for this also shows the additional READ_PHONE_STATE permission.
Are there cases where permissions can be/are 'implied' (in code, by feature use, etc) that would not be required in the Android Manifest? Or put another way, why does aapt return one set of permissions and the getPackageManager().getPackageInfo() API return a different set?
EDIT:
Searching with "more better" terms discovered the answer I was looking for: Android permissions: Phone Calls: read phone state and identity
In short, APKs compiled with earlier version of the SDK did inherit some permissions for free...
As far as I know permissions must always be explicitly set in the manifest.
If an application needs access to a feature protected by a permission, it must declare that it requires that permission with a element in the manifest. Then, when the application is installed on the device, the installer determines whether or not to grant the requested permission by checking the authorities that signed the application's certificates and, in some cases, asking the user. If the permission is granted, the application is able to use the protected features. If not, its attempts to access those features will simply fail without any notification to the user.
source
The difference you are seeing I believe is due to the protectionLevel attribute on permissions. Any permissions that are set to "normal" are not required to be OK'd by the user so they just show up in the Details section.
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.