I'm wondering about how is a signatureOrSystem permissions enforced on custom ROMs.
Docs say:
A permission that the system grants only to applications that are in the Android system image or that are signed with the same certificates as those in the system image.
Where is this certificate? In case I'm using a custom ROM, say CyanogenMod, can I obtain their certificate, which I'm assuming is freely available, and sign my application so that it could use such a permission (only with that ROM of course)?
Thanks ;)
For CygenMod the platform key is here: https://github.com/CyanogenMod/android_build/tree/gingerbread/target/product/security.
As of Android 4.4 putting the app in "/system/priv-app" will also enable granting of permissions marked as "signatureOrSystem" regardless of what key the app is signed with. In theory older androids would do the same for an app on "/system". However, I was not able to get this to work.
As of Android 5.1 all apps in /system/priv-app may have to be in subfolder with their name to work.
Notice: The special handling of "/system/priv-app" is currently an undocumented feature.
Related
As seen in this answer, starting from Android 6.0 Marshmallow, system apps are no longer granted dangerous permissions by default. I also read that only apps signed with the platform key have the old behavior.
Is there a way to add other apps to "trusted" ones? Is it possible, as a ROM developer, to add another trusted key beside the platform one?
I want to enable android.permissions.STATUS_BAR in my app. Is it possible to do so, given that I am targeting possibly non-rooted phones?
From what I understand, android.persmissions.STATUS_BAR is a System persmission and can't be used.
In android terms it falls under signatureOrSystem permission. The meaning is (taken from Android Manifest DOCS)...
A permission that the system grants only to applications that are in the Android system image or that are signed with the same certificate as the application that declared the permission. Please avoid using this option, as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed. The "signatureOrSystem" permission is used for certain special situations where multiple vendors have applications built into a system image and need to share specific features explicitly because they are being built together.
Have a look at the following links as well. They might help you find a workaround...
How to disable statusbar in android
Why are these permissions being refused?
Preventing status bar expansion
I want to create an system application(while installing it will ask user permission to make it as system app) for UN-rooted application. As I am not familiar in android, please tell me how to create it.
Thanks in advance.
True system apps are baked into the ROM image, and signed with the same key the ROM was signed with, giving them extra access to the system.
You cannot add a new system app on the same level without updating the ROM image of the device, and even then you'll need the OEM key to sign your app and you will have to request them to include it in their ROM.
Having a rooted device allows standard apps to gain extra access without being system apps.
I'm developing a remote-control application for Android.
I want to be able to lock/unlock the screen.
To do this there are two ways:
Making the app a Device Administrator.
Using PowerManager.goToSleep(), which requires the DEVICE_POWER permission, which is a system permission.
So eclipse tells me "this permission is only granted to system apps".
I really need this and some other system permissions in my app, as it's a remote control app that must be able to control system features.
From the support page:
Uploading System Applications
Most developers will not need to upload system applications and may ignore this section. System applications may come pre-installed on certain devices and may or may not already be published in the Play store.
If you need to upload a system application and encounter an error message when doing so, please contact us. Please be sure to select the Publishing issues and distribution option.
If I'm understanding it right, It's possible to make a system application. how?
I'm developing a remote-control application for Android
Fortunately, this is not possible, except perhaps if you run as root, or you download the Android source code, modify it, and roll it into your own ROM mod.
If I'm understanding it right, It's possible to make a system application. how?
Build your own ROM mod. Sign the app with the same signing key as is used to sign your ROM mod. Put your app in your ROM mod. Install your ROM mod on your device.
This, of course, will limit your app's distribution to those devices running your ROM mod.
A lot of “system” permissions are really SIGNATURE_OR_SYSTEM permissions. For those, you need to do one of the following:
After building the APK, install it as a system app.
Sign the app with the same key as the Android distribution on your device.
For the first option, you would need to be root on your device. Regular APKs reside in /data/app, while system APKs need to be placed in a different folder (on Android 6 and 7 it’s /system/priv-app, earlier versions may differ). However, this is not very suitable for an app to be distributed to end users, especially if your target audience is not very tech-savvy.
For the second option, you need to build Android from source for your target device. If you sign the app with the same key as your Android build, then users running that build of Android can install it in the usual manner.
Can somebody explain to me what are the benefits of Android System App over a "normal" app
(besides that fact that a system app cannot be uninstalled)?
Special permissions?
There is some confusion here.
First, if you are talking about "system app" as just being one with FLAG_SYSTEM set, all this means is that the app is located on the /system partition, which is the read-only partition that is basically the firmware of the device. (It can only be modified as part of an OTA firmware update.) These apps can't be removed simply because they are on a partition that can't be modified.
The only thing special about a system application beyond this is that there are a handful of signature permissions that can also be granted to any app on the system image. For example there is a permission to directly talk with the package manager to install an app (without going through the system UI) that such an app can have; this is useful for any app store / market pre-loaded on a device.
Being signed with the platform certificate is an orthogonal concept -- such an app can be either on the system image or installed as a third party app (though obviously in almost all cases these come pre-installed). Such apps have access to a whole suite of low-level permissions for interacting with the platform. Very few apps are signed with this certificate; it is only for core platform applications. Unless you are working with a hardware vendor on a device, you won't have access to this.
All of the platform's certificates (whether they be available to all apps, require an app be signed with the platform cert, or are available to apps installed on the system partition) are declared by the platforms manifest, just like any other app:
https://android.googlesource.com/platform/frameworks/base/+/master/core/res/AndroidManifest.xml
There are permissions that can only be obtained by systems apps. For example the permission brick can be requested by every app but it is only granted to apps that are signed as system apps. There are some other features that make more sense I think directly installing and removing apps would be a system only permission too.
From your explanation I guess you mean the the pre-installed applications (like the Browser or the Messages app). You can take a look in these apps at https://android.googlesource.com. (search for platform/packages/apps/...).
You will find that these application are no difference to your own custom developed Apps, except you can't remove them. They cannot be removed as they provide the basic functionality to operate your phone / device. So, same security constraints apply there.