I want to add this permission to my Android manifest:
<uses-permission android:name="android.permission.MODIFY_PHONE_STATE" />
But after I paste this permission in my manifest, it tests red underline and says:
permission is only granted to system apps
What can I do?
MODIFY_PHONE_STATE permission is granted to system apps only.
For your information, there are 2 types of Android apps: system & user
User apps are just all your normal app installations through the Google Play Store, Amazon Appstore or sideloading. These go into the /data partition of your Android phone, which is the part of the internal memory made available for user data and apps.
System apps are basically the apps that come pre-installed with your ROM. In a standard Android user environment, the user doesn’t have write access to the /system partition and thus, installing or uninstalling system apps directly isn’t possible.
In order to install an app as a system app on your Android device,
your device must either be rooted or have a custom recovery installed (or both).
That being said, that error is actually wrong because you have a valid code and compilation should work. It would be better if it gave a warning instead. In Eclipse you can easily fix it. Just go to:
Window -> Preferences -> Android -> Lint Error Checking.
Find ProtectedPermission from the list and set the severity to something other than error(info for example). This way your project will still compile.
MODIFY_PHONE_STATE is a system-only permission. System Apps are either pre-installed into a system folder or compiled by a manufacturer using their security certificate.
Hence, if you are trying to do this you are trying to use API which are no longer supported. With Android versions 2.3+ you can monitor incoming calls, but blocking is not allowed (i think from the link you posted thats what you're trying to do).
Android issues if you need to follow: Issue 15022 and Issue 14789
This error appears in SDK 19 onwards, when you change the manifest.
Do Project Clean and Build.
It should clear this error.
just clean your project it will be fine like this :
project > Clean...
There are four types of Permission
Regular
Dangerous
Signed
Signed or System
The first two can be used by Simple Apps Other two can only be used by the app which is build in framework
Because this is the system level permission device developer not grant this so application development tools also warn against this so you have to
Simply Clean project & Rebuild this is it
Find ProtectedPermission from the list in
Window -> Preferences -> Android -> Lint Error Checking.
and set the severity to something other than error(info for example). This way your project will still compile.
Related
recently I get Installed blocked : The app permissions error error when updating my application(in app updating).
I know my app signatures are same because I can install new app manually.
can some know why this happen?
Do you think I need to grant android.permission.INSTALL_PACKAGES while I granted android.permission.REQUEST_INSTALL_PACKAGES? if yes can explain deference of both?
Note: my application updated correctly in many devices!! but in some devices(android Version: 5.1.1) have problem!!!
The INSTALL_PACKAGES permission allows an application to install packages. It is not for use by third-party applications.
Developers of apps that require the ability to download and install other apps via the Package Installer may need to make some changes. If an app uses a targetSdkLevel of 26 or above and prompts the user to install other apps, the manifest file needs to include the REQUEST_INSTALL_PACKAGES permission.
Read more here: https://android-developers.googleblog.com/2017/08/making-it-safer-to-get-apps-on-android-o.html?m=1
I am having an app which is targeting android 27 API. I am testing this app from playstore on device Android Q which work managed device.
Steps i followed on device Android Q having build build 6-
Installed app and allowed all the permissions(additional permission also which are custom permissions).
Uninstalled app from device.
Installed again app from playstore and found that app is asking custom permission only instead no permission.
Is it the expected behavior? Anyone know how this is?
This is something called Auto Backup.
Files that are backed up
By default, Auto Backup includes files in most of the directories that
are assigned to your app by the system:
Shared preferences files.
Files saved to your app's internal storage, accessed by getFilesDir() or getDir(String, int).
Files in the
directory returned by getDatabasePath(String), which also includes
files created with the SQLiteOpenHelper class.
Files on external
storage in the directory returned by getExternalFilesDir(String).
Auto Backup excludes files in directories returned by getCacheDir(),
getCodeCacheDir(), or getNoBackupFilesDir(). The files saved in these
locations are only needed temporarily, or are intentionally excluded
from backup operations.
You can manage it by AndroidManifest.xml. See android:allowBackup
<manifest ... >
...
<application android:allowBackup="true" ... >
...
</application>
</manifest>
EDIT
android:fullBackupContent="false"
android:fullBackupOnly="false"
There are 2 more rules available to set.
EDIT 2
I just found more useful information at the android official website. see here
Note: Any permissions a user grants to your app are automatically
backed up and restored by the system on devices running Android 7.0
(API 24) or newer. However, if a user uninstalls your app, then the
system clears any granted permission and the user must grant them
again.
My best guess is there should be some difference(like 24hours) until the user settings/permissions will be deleted from the system device/cloud.
Hopes this will answer your query in some way.
Regarding whether this is an expected behavior in Android Q:
This issue does not reproduce on Android Q emulator. I guess it counts as a baseline.
More technical details:
Runtime permissions logic in Android is mostly located in PackageManagerService (mostly book keeping for each package) and ActivityManagerService (mostly request runtime permission logic)
When package gets deleted, the data cleanup method removePackageDataLIF
gets called. It is responsible for cleaning up everything including the app permissions. This logic hasn't changed Android Q.
The permissions info is stored in system data directory, not the application's so the app data backup doesn't affect it either.
But the question remains: How could this happen?
One of the possible explanations could be the flag PackageManager.DELETE_KEEP_DATA
You can easily delete package while keeping its data directory after uninstall:
$ adb shell cmd package uninstall -k your.app.id
(-k is for keep data)
Now to check whether the permissions are kept in place along with the data directory:
$ adb root && adb shell cat /data/system/users/0/runtime-permissions.xml | grep your.app.id -A 10
(this command requires a debuggable phone firmware build)
Looking at the source of removePackageDataLIF and trying it on my Pixel with debuggable firmware the application permission is kept intact if you kept its data.
Another explanation
PackageManagerService has an another interesting method setKeepUninstalledPackages Which basically forces android to keep all the data for specified apps even if they were uninstalled.
As you said the device is work managed. Usually management is done with DevicePolicyManager. One of the available policies is setKeepUninstalledPackages, which calls the mentioned above PackageManagerService method.
Please check your Device admin app code to verify.
I have access to an Android tablets' platform key and certificate. I'm attempting to build an app and install it with system level privileges by doing the following:
Create a Java KeyStore file with platform.pk8 and platform.x509.pem using the bash script called platform_import_keystore found on GitHub.
In AndroidManifex.xml add the following:
<uses-permission android:name="android.permission.READ_LOGS"/>
android:sharedUserId="android.uid.system"
Sign APK with PLATFORM key and certificate using a Java KeyStore file in Android Studio.
Install APK
When the app runs, the system denies READ_LOGS permission.
Why isn't my app running with system level permissions?
What #Mark mentions is correct to some extent, for system apps.
I think you are doing something else wrong.
I have tried this with system apps as well, and as long it was signed with the platform keystore, it works. Now this was on Android 8 and Android 9. You haven't mentioned the AOSP version running the device.
That changes things AFAIK, so if it's AOSP 10+, it might behave differently.
Also the other comments are missing another key thing SELinux. SELinux is not permissive for user builds. Verity is enabled, and you cannot have root access. So you cannot push the app into /system/priv-app/ or push it into /vendor/app/.
You cannot access system resources without proper SE Policy files. You can check the logs yourself, to see avc denied messages.
I think overall what you are seeing should be inline with AOSP's security ideals. An app signed with System keys should not be able to get system permissions. It also needs to be located in the correct place, either as a privileged app or vendor app. Such apps need to be whitelisted. There's a built in script in AOSP source to even generate the permissions for whitelisting (it produces the required xml)
There's two classes of system apps, /system/app/ and /system/priv-app/
The privileged apps are the only ones that get signature level permissions, and according to newer versions of android, you need to enable whitelisting in the /system/etc/priv_app-permissions_device_name.
If you make any changes to the system or vendor when verity is enabled, firstly they are mounted read only, but somehow if you do make a change, the device will brick itself. This is the security feature. All custom development needs to be done in userdebug builds with SELinux in permissive mode, and then all the permissions need to be predefined, SE Policies fine tuned to utmost minimal, only then the user build can function normally. User build is not at all suitable for AOSP development activities, even if it's just for testing or trying out a single app.
User build is production type build that the end user can use and is not for development. It's the most secure form of android, so if you have platform keys, it may never be enough.
All that being said, I'm sure you don't have the right keys. Just pull an app from system/priv-app/ and use keytool or similar to check it's signature, and then try to match with your release apk.
It's little complicated as it is, and kind of hard to explain and there are levels of permissions also in android, so if you aren't following a specific approach/path, you will not be able to get it to work.
I am maintaining one existing (very-huge, very-sensitive) Android Application.
The other day, I have received an email from my client that, the Application might be declaring the Permissions that are not actively being used.
For example, they wants me to remove "WRITE_EXTERNAL_STORAGE" permission.
I have removed it and compiled it and run the App. There is NO error at all.
But, just because of that, I don't think I can assume that permission is not actively being used at all.
My question is "Is there anyway I can easily and simply check the permission if it is actively being used ?"
Frankly, I don't want to go through every little detail aspect of that application just to fine out the permission is required or not.
I just don't have time.
My goal is check if the permission is actively being used. If not, remove the permission.
Hope there is an less-time consuming way for that.
Regards
In Android Studio 1.3 & Android Support Library v7:22.2.0, you have solution for it.
Steps:
Update Android Studio to V1.3
Update your Android Support Library to v7:22.2.0
Run Android Lint (Analyse -> Inspect Code), In Lint Error see for Type "Android -> Constant & Resource Type MisMatch", Which shows all methods which requires permission.
Explanation
Android has introduced new annotation #requirespermission.
All SDK methods which requires permission are annotated with #requirespermission.
When we call any sdk method which requires permission without properly checking whether we have permission or not, Android studio will through lint error.
There is a group at Berkeley that wrote a paper about Android permissions. They talk about over-permissions and developed a tool called Stowaway that would analyze your APK for unused permissions. The analysis was based on the app's API calls and their own mapping of the permissions needed for each API call (see the paper for details). The tool throws a flag if there is a permission in the manifest that is not mapped to any of the API calls found in the APK.
For a while, a web-based version of the tool was available at http://www.android-permissions.org/, but it is from the Gingerbread era and was never updated. The page now suggests using PScout.
PScout does a better job than Stowaway at generating the permission maps. However, PScout does not include an APK analyzer, so you will have to manually compare the mappings they provide with API calls made by your app. Unfortunately, if you're interested in maps for versions beyond 5.1.1, you'll have to generate them yourself using the provided PScout code and your own Framework source.
You might also check out the various APK analyzers here to see if they include the functionality you are looking for.
I tried the method suggested by Vasanth but it doesn't work for me. In fact, because my project has flavors and Code Inspection doesn't work for the project with flavors. See https://code.google.com/p/android/issues/detail?id=210073.
But Running Lint from console works. So steps are simple:
Remove permissions from your manifest.
Run Lint for flavor as described here https://stackoverflow.com/a/32708435/1170154.
Open Lint result and find section Correctness > Error MissingPermission: Missing Permissions. It will contain all calls that require permissions.
As of Android Studio 3.3, running Analyze → Inspect Code will inform you of missing permissions under Android → Lint → Correctness → Missing Permissions
I am building an app that will be bundled on an android device as a system app. The manufacturer is a ways out on delivering the device to us, so in the meantime I'd like to grant my app system level permissions in the emulator so I can work on an auto update feature that will do silent installs of APKs without any interactions from the user. From what I've read, its my understanding that the only way to be able to do silent installs on android is if your app is signed with the same cert as the OS. So how can I simulate this in the emulator?
If you want a signatureOrSystem permission, you just need to be placed on the system image; you don't need to be signed with any special cert. You can do this as a one-off (until you exit the emulator) like this:
> adb root
> adb remount
> adb push /path/to/My.apk /system/app/My.apk
Once you have done that, you can use the normal process to install further updates on the data partition ("adb install -r /path/to/My.apk" which is what the developer tools do when you run from Eclipse). When installing this way, the app retains any signatureOrSystem permissions it had requested from the original version on the system image, but can not gain any new such permissions.
If you need pure signature permissions, you need to sign your app with the same cert as whatever is declaring those permissions (typically the core framework, but the media system is a separate cert etc). If you are requesting signature permissions you don't need to be installed on the system image, you can just install it as a normal app and it can still get the permissions because of the signing.
As far as I can tell, you need to:
download the Android source and build an emulator firmware image.
sign your application with the keys in the Android source tree at /build/target/product/security/.
add android:sharedUserId="android.uid.system" to your application's manifest.
run your application on an emulator using the image built in step 1.
The reason for having to build your own firmware image is so that you can get at the keys. Now, it might be possible that the keys for the standard emulator image are available somewhere, which will save you the long and exceedingly tedious process of building your own Android, but I'm afraid I have no idea where these might be.
Disclaimer: never tried this myself.