The developer doc: Requesting Permissions at Run Time clearly mentions what runtime permission is and how to use it. And I am able to execute them as well.
However, the question is : where does Android store the run-time permission values?
ie, when the user deletes the data associated with the app, the permissions are reset, so where do Android store these values? (is it in the app cache or in any other place). And in what format ? ( is it a database or a sharedpreferences file or any other) And how are they stored? (encryped or non-encrypted) .
Searched in many existing answers and developer docs, however couldn't find any useful info in this regard. Any help will be much appreciated.
I'm not sure if you found the answer to this or not, but they are stored in:
/data/system/users/0/runtime-permissions.xml
When the system is reset, or a new user created, the system also populates this with system app permissions to auto grant them. I have been trying to research how to auto grant permissions to system apps.
See this answer for more details.
In Android 12 on Samsung phones it's:
/data/misc_de/0/apexdata/com.android.permission/runtime-permissions.xml
Can't confirm it for others.
0 seems to be the user-id.
Found by running:
find / -name '*permission*.xml' 2>/dev/null
Related
I want to get all the list of all permissions granted to each and every app. It is very frustrating to do it manually by getting permission list of each app separately. Is there a way to automatically put the list into some text file (.txt), for example I may run a series of Windows PowerShell commands to do it iteratively (using loops?) ? If there is share it.
I tried searching the internet but could not find anything useful. There are ways to get permission manually for each app, given on this link Listing permissions of Android application via adb but I cant find a way to generalize.
Since the new ADT preview version (version 21), they have a new lint warning that tells me the next thing on the manifest file (in the application tag):
Should explicitly set android:allowBackup to true or false (it's true by default, and that can have some security implications for the application's data)
In the official website, they've written:
A couple of new checks: you must explicitly decide whether your app allows backups, and a label check. There's a new command line flag for setting the library path. Many improvements to the incremental lint analysis while editing.
What is this warning? What is the backup feature, and how do I use it?
Also, why does the warning tell me it has security implications? What are the disadvantages and advantages of disabling this feature?
There are two concepts of backup for the manifest:
"android:allowBackup" allows to backup and restore via adb, as shown here:
Whether to allow the application to participate in the backup and
restore infrastructure. If this attribute is set to false, no backup
or restore of the application will ever be performed, even by a
full-system backup that would otherwise cause all application data to
be saved via adb. The default value of this attribute is true.
This is considered a security issue because people could backup your app via ADB and then get private data of your app into their PC.
However, I think it's not that of a problem, since most users don't know what adb is, and if they do, they will also know how to root the device. ADB functions would only work if the device has the debugging feature enabled, and this needs the user to enable it.
So, only users that connect their devices to the PC and enable the debugging feature would be affected. If they have a malicious app on their PC that uses the ADB tools, this could be problematic since the app could read the private storage data.
I think Google should just add a feature that is disabled by default, in the developer category, to allow backup&restore of apps via ADB.
"android:backupAgent" allows to use the backup and restore feature of the cloud, as shown here and here:
The name of the class that implement's the application's backup agent,
a subclass of BackupAgent. The attribute value should be a fully
qualified class name (such as, "com.example.project.MyBackupAgent").
However, as a shorthand, if the first character of the name is a
period (for example, ".MyBackupAgent"), it is appended to the package
name specified in the element. There is no default. The
name must be specified.
This isn't a security issue.
For this lint warning, as for all other lint warnings, note that you can get a fuller explanation than just what is in the one line error message; you don't have to search the web for more info.
If you are using lint via Eclipse, either open the lint warnings view, where you can select the lint error and see a longer explanation, or invoke the quick fix (Ctrl-1) on the error line, and one of the suggestions is "Explain this issue", which will also pop up a fuller explanation. If you are not using Eclipse, you can generate an HTML report from lint (lint --html <filename>) which includes full explanations next to the warnings, or you can ask lint to explain a particular issue. For example, the issue related to allowBackup has the id AllowBackup (shown at the end of the error message), so the fuller explanation is:
$ ./lint --show AllowBackup
AllowBackup
-----------
Summary: Ensure that allowBackup is explicitly set in the application's
manifest
Priority: 3 / 10
Severity: Warning
Category: Security
The allowBackup attribute determines if an application's data can be backed up and restored, as documented here.
By default, this flag is set to true. When this flag is set to true, application data can be backed up and restored by the user using adb backup and adb restore.
This may have security consequences for an application. adb backup allows users who have enabled USB debugging to copy application data off of the device. Once backed up, all application data can be read by the user. adb restore allows creation of application data from a source specified by the user. Following a restore, applications should not assume that the data, file permissions, and directory permissions were created by the application itself.
Setting allowBackup="false" opts an application out of both backup and restore.
To fix this warning, decide whether your application should support backup and explicitly set android:allowBackup=(true|false)
Click here for More information
Here is what backup in this sense really means:
Android's backup service allows you to copy your persistent application data to remote "cloud" storage, in order to provide a restore point for the application data and settings. If a user performs a factory reset or converts to a new Android-powered device, the system automatically restores your backup data when the application is re-installed. This way, your users don't need to reproduce their previous data or application settings.
~Taken from http://developer.android.com/guide/topics/data/backup.html
You can register for this backup service as a developer here:
https://developer.android.com/google/backup/signup.html
The type of data that can be backed up are files, databases, sharedPreferences, cache, and lib. These are generally stored in your device's /data/data/[com.myapp] directory, which is read-protected and cannot be accessed unless you have root privileges.
UPDATE:
You can see this flag listed on BackupManager's api doc: BackupManager
This is not explicitly mentioned, but based on the following docs, I think it is implied that an app needs to declare and implement a BackupAgent in order for data backup to work, even in the case when allowBackup is set to true (which is the default value).
http://developer.android.com/reference/android/R.attr.html#allowBackup
http://developer.android.com/reference/android/app/backup/BackupManager.html
http://developer.android.com/guide/topics/data/backup.html
It is privacy concern. It is recommended to disallow users to backup an app if it contains sensitive data. Having access to backup files (i.e. when android:allowBackup="true"), it is possible to modify/read the content of an app even on a non-rooted device.
Solution - use android:allowBackup="false" in the manifest file.
You can read this post to have more information:
Hacking Android Apps Using Backup Techniques
Here you can see android official doc
https://developer.android.com/reference/android/R.attr#allowBackup
Since the new ADT preview version (version 21), they have a new lint warning that tells me the next thing on the manifest file (in the application tag):
Should explicitly set android:allowBackup to true or false (it's true by default, and that can have some security implications for the application's data)
In the official website, they've written:
A couple of new checks: you must explicitly decide whether your app allows backups, and a label check. There's a new command line flag for setting the library path. Many improvements to the incremental lint analysis while editing.
What is this warning? What is the backup feature, and how do I use it?
Also, why does the warning tell me it has security implications? What are the disadvantages and advantages of disabling this feature?
There are two concepts of backup for the manifest:
"android:allowBackup" allows to backup and restore via adb, as shown here:
Whether to allow the application to participate in the backup and
restore infrastructure. If this attribute is set to false, no backup
or restore of the application will ever be performed, even by a
full-system backup that would otherwise cause all application data to
be saved via adb. The default value of this attribute is true.
This is considered a security issue because people could backup your app via ADB and then get private data of your app into their PC.
However, I think it's not that of a problem, since most users don't know what adb is, and if they do, they will also know how to root the device. ADB functions would only work if the device has the debugging feature enabled, and this needs the user to enable it.
So, only users that connect their devices to the PC and enable the debugging feature would be affected. If they have a malicious app on their PC that uses the ADB tools, this could be problematic since the app could read the private storage data.
I think Google should just add a feature that is disabled by default, in the developer category, to allow backup&restore of apps via ADB.
"android:backupAgent" allows to use the backup and restore feature of the cloud, as shown here and here:
The name of the class that implement's the application's backup agent,
a subclass of BackupAgent. The attribute value should be a fully
qualified class name (such as, "com.example.project.MyBackupAgent").
However, as a shorthand, if the first character of the name is a
period (for example, ".MyBackupAgent"), it is appended to the package
name specified in the element. There is no default. The
name must be specified.
This isn't a security issue.
For this lint warning, as for all other lint warnings, note that you can get a fuller explanation than just what is in the one line error message; you don't have to search the web for more info.
If you are using lint via Eclipse, either open the lint warnings view, where you can select the lint error and see a longer explanation, or invoke the quick fix (Ctrl-1) on the error line, and one of the suggestions is "Explain this issue", which will also pop up a fuller explanation. If you are not using Eclipse, you can generate an HTML report from lint (lint --html <filename>) which includes full explanations next to the warnings, or you can ask lint to explain a particular issue. For example, the issue related to allowBackup has the id AllowBackup (shown at the end of the error message), so the fuller explanation is:
$ ./lint --show AllowBackup
AllowBackup
-----------
Summary: Ensure that allowBackup is explicitly set in the application's
manifest
Priority: 3 / 10
Severity: Warning
Category: Security
The allowBackup attribute determines if an application's data can be backed up and restored, as documented here.
By default, this flag is set to true. When this flag is set to true, application data can be backed up and restored by the user using adb backup and adb restore.
This may have security consequences for an application. adb backup allows users who have enabled USB debugging to copy application data off of the device. Once backed up, all application data can be read by the user. adb restore allows creation of application data from a source specified by the user. Following a restore, applications should not assume that the data, file permissions, and directory permissions were created by the application itself.
Setting allowBackup="false" opts an application out of both backup and restore.
To fix this warning, decide whether your application should support backup and explicitly set android:allowBackup=(true|false)
Click here for More information
Here is what backup in this sense really means:
Android's backup service allows you to copy your persistent application data to remote "cloud" storage, in order to provide a restore point for the application data and settings. If a user performs a factory reset or converts to a new Android-powered device, the system automatically restores your backup data when the application is re-installed. This way, your users don't need to reproduce their previous data or application settings.
~Taken from http://developer.android.com/guide/topics/data/backup.html
You can register for this backup service as a developer here:
https://developer.android.com/google/backup/signup.html
The type of data that can be backed up are files, databases, sharedPreferences, cache, and lib. These are generally stored in your device's /data/data/[com.myapp] directory, which is read-protected and cannot be accessed unless you have root privileges.
UPDATE:
You can see this flag listed on BackupManager's api doc: BackupManager
This is not explicitly mentioned, but based on the following docs, I think it is implied that an app needs to declare and implement a BackupAgent in order for data backup to work, even in the case when allowBackup is set to true (which is the default value).
http://developer.android.com/reference/android/R.attr.html#allowBackup
http://developer.android.com/reference/android/app/backup/BackupManager.html
http://developer.android.com/guide/topics/data/backup.html
It is privacy concern. It is recommended to disallow users to backup an app if it contains sensitive data. Having access to backup files (i.e. when android:allowBackup="true"), it is possible to modify/read the content of an app even on a non-rooted device.
Solution - use android:allowBackup="false" in the manifest file.
You can read this post to have more information:
Hacking Android Apps Using Backup Techniques
Here you can see android official doc
https://developer.android.com/reference/android/R.attr#allowBackup
Since the new ADT preview version (version 21), they have a new lint warning that tells me the next thing on the manifest file (in the application tag):
Should explicitly set android:allowBackup to true or false (it's true by default, and that can have some security implications for the application's data)
In the official website, they've written:
A couple of new checks: you must explicitly decide whether your app allows backups, and a label check. There's a new command line flag for setting the library path. Many improvements to the incremental lint analysis while editing.
What is this warning? What is the backup feature, and how do I use it?
Also, why does the warning tell me it has security implications? What are the disadvantages and advantages of disabling this feature?
There are two concepts of backup for the manifest:
"android:allowBackup" allows to backup and restore via adb, as shown here:
Whether to allow the application to participate in the backup and
restore infrastructure. If this attribute is set to false, no backup
or restore of the application will ever be performed, even by a
full-system backup that would otherwise cause all application data to
be saved via adb. The default value of this attribute is true.
This is considered a security issue because people could backup your app via ADB and then get private data of your app into their PC.
However, I think it's not that of a problem, since most users don't know what adb is, and if they do, they will also know how to root the device. ADB functions would only work if the device has the debugging feature enabled, and this needs the user to enable it.
So, only users that connect their devices to the PC and enable the debugging feature would be affected. If they have a malicious app on their PC that uses the ADB tools, this could be problematic since the app could read the private storage data.
I think Google should just add a feature that is disabled by default, in the developer category, to allow backup&restore of apps via ADB.
"android:backupAgent" allows to use the backup and restore feature of the cloud, as shown here and here:
The name of the class that implement's the application's backup agent,
a subclass of BackupAgent. The attribute value should be a fully
qualified class name (such as, "com.example.project.MyBackupAgent").
However, as a shorthand, if the first character of the name is a
period (for example, ".MyBackupAgent"), it is appended to the package
name specified in the element. There is no default. The
name must be specified.
This isn't a security issue.
For this lint warning, as for all other lint warnings, note that you can get a fuller explanation than just what is in the one line error message; you don't have to search the web for more info.
If you are using lint via Eclipse, either open the lint warnings view, where you can select the lint error and see a longer explanation, or invoke the quick fix (Ctrl-1) on the error line, and one of the suggestions is "Explain this issue", which will also pop up a fuller explanation. If you are not using Eclipse, you can generate an HTML report from lint (lint --html <filename>) which includes full explanations next to the warnings, or you can ask lint to explain a particular issue. For example, the issue related to allowBackup has the id AllowBackup (shown at the end of the error message), so the fuller explanation is:
$ ./lint --show AllowBackup
AllowBackup
-----------
Summary: Ensure that allowBackup is explicitly set in the application's
manifest
Priority: 3 / 10
Severity: Warning
Category: Security
The allowBackup attribute determines if an application's data can be backed up and restored, as documented here.
By default, this flag is set to true. When this flag is set to true, application data can be backed up and restored by the user using adb backup and adb restore.
This may have security consequences for an application. adb backup allows users who have enabled USB debugging to copy application data off of the device. Once backed up, all application data can be read by the user. adb restore allows creation of application data from a source specified by the user. Following a restore, applications should not assume that the data, file permissions, and directory permissions were created by the application itself.
Setting allowBackup="false" opts an application out of both backup and restore.
To fix this warning, decide whether your application should support backup and explicitly set android:allowBackup=(true|false)
Click here for More information
Here is what backup in this sense really means:
Android's backup service allows you to copy your persistent application data to remote "cloud" storage, in order to provide a restore point for the application data and settings. If a user performs a factory reset or converts to a new Android-powered device, the system automatically restores your backup data when the application is re-installed. This way, your users don't need to reproduce their previous data or application settings.
~Taken from http://developer.android.com/guide/topics/data/backup.html
You can register for this backup service as a developer here:
https://developer.android.com/google/backup/signup.html
The type of data that can be backed up are files, databases, sharedPreferences, cache, and lib. These are generally stored in your device's /data/data/[com.myapp] directory, which is read-protected and cannot be accessed unless you have root privileges.
UPDATE:
You can see this flag listed on BackupManager's api doc: BackupManager
This is not explicitly mentioned, but based on the following docs, I think it is implied that an app needs to declare and implement a BackupAgent in order for data backup to work, even in the case when allowBackup is set to true (which is the default value).
http://developer.android.com/reference/android/R.attr.html#allowBackup
http://developer.android.com/reference/android/app/backup/BackupManager.html
http://developer.android.com/guide/topics/data/backup.html
It is privacy concern. It is recommended to disallow users to backup an app if it contains sensitive data. Having access to backup files (i.e. when android:allowBackup="true"), it is possible to modify/read the content of an app even on a non-rooted device.
Solution - use android:allowBackup="false" in the manifest file.
You can read this post to have more information:
Hacking Android Apps Using Backup Techniques
Here you can see android official doc
https://developer.android.com/reference/android/R.attr#allowBackup
I need to read a db file from a different application. The db file is created by the specific provider app & my application has to read this db file and take a back up. Not able to access the file : Permission Denied.
Is it possible to read the file created by a different app? I think it may not be possible as per the android design, but just wanted to confirm whether it is possible by setting any permission.
Thanks,
Grace.
No its not possible to read a db file from a different app in Android unless both apps are from the same publisher. It is part of the android security model that the application DB files are set as readable only by the application publisher in question.
This is done by each publisher being given their own user id on the device.
The only work rounds are
Root you android device ( If you break it you get to keep both pieces ) and run your app with elevated privs.
Look to see if the app in question has some kind of published API for querying their data.
Hope this helps
Peter