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
Related
By "permanent" I mean that it resists the application uninstall option that the Android OS offers. Obviously you cannot make a file not deletable in the user's terminal, at the very least, the user will always be able to delete it via the file manager if he wishes so.
I'd need this because in my app when some actions have been performed the app forbids from doing some more. So far this is controlled via a file, but there's nothing that prevents the user from uninstalling the app, and with a new fresh install this doesn't happen anymore.
I could implement some type of server-side logic to prevent the user from continueing but:
1) It's way easier to prevent just by checking the file.
2) It's not that important what happens if the user manages to bypass this security measure, so I don't really mind if a few of them are able to bypass the protection, as long as the file can be "permanent" and is in some obscure directory, not many users are going to be able to perform the mentioned behavior.
Is there any way to do this?
Just get the write file permission and write the file to the root file directory. As described here: https://developer.android.com/training/data-storage/files#WriteExternalStorage
After you request storage permissions and verify that storage is
available, you can save two different types of files:
Public files: Files that should be freely available to other apps and to the user. When the user uninstalls your app, these files should
remain available to the user. For example, photos captured by your app
or other downloaded files should be saved as public files.
Private files: Files that rightfully belong to your app and will be deleted when the user uninstalls your app. Although these files are
technically accessible by the user and other apps because they are on the external storage, they don't provide value to the user outside of your app.
this can be done by configuring auto-backup, assuming that the user has it enabled.
for example, here I've explained how to disable that behavior in debug mode.
the advance is, that it works across several devices, bound to the account.
instead of file , I would suggest to use following intent to catch uninstalling your app and put your logic to allow or deny for uninstall
ACTION_PACKAGE_REMOVED -: Broadcast Action: An existing application package has been removed from the device. The data contains the name of the package. The package that is being installed does not receive this Intent.
ACTION_PACKAGE_FULLY_REMOVED - : Broadcast Action: An existing application package has been completely removed from the device. The data contains the name of the package. This is like ACTION_PACKAGE_REMOVED, but only set when EXTRA_DATA_REMOVED is true and EXTRA_REPLACING is false of that broadcast.
In my Android app I use a set of randomly generated file names to store some data. In order to ensure that the same set of file names are generated at app restart - and are yet different for each app installation - I start off the process by picking the names as substrings from a long string of random alphanumeric characters which I generate when the app is installed. This latter string is stored in Shared Prefereneces.
As I am testing out the app I have run into a rather peculiar issue. From time-to-time I make major changes so I fully uninstall the app - and even Force Close it + clear all its data. At that point I would expect that the device would have no "prior knowledge" of the app if it is reinstalled. And yet I find that the Shared Preferences string is somehow "remembered". This causes havoc if in the interim I have changed how the file name substrings are picked up from the stored shared preferences string.
How can I ensure that the app has "zero memory" of a previously installed version that has subsequently been uninstalled?
One solution I have used in the past is to instruct Android not to do any backups via the manifest file, android:allowBackup = "false". However, I have backed away from that idea since - unless I am mistaken - it effectively means that I am stopping the user from porting their app over to a new device when they decide to change handsets.
On (re)install, your app may be restoring files from Google auto-backup (via Google Drive). To disable this feature, you can explicitly set it to false in the manifest:
<manifest ... >
...
<application android:allowBackup="false" ... >
...
</application>
</manifest>
If you'd like more granular control over what is backed up/restored and what is not, you can include or exclude specific files from the backups.
See auto backup documentation:
https://developer.android.com/guide/topics/data/autobackup#EnablingAutoBackup
If you don't want to disable auto backups, but want to reinstall with a "clean slate" (for testing purposes), you can do one of the following:
Clear app data after reinstall. This will wipe out files that were restored automatically on install
Clear app data prior to uninstall, then force a new backup (so old one gets reset) by using this command: adb shell bmgr backupnow <PACKAGE>
See how to test backups documentation:
https://developer.android.com/guide/topics/data/testingbackup#TestingBackup
To extend on this, for example mobile/src/debug/AndroidManifest.xml
<application
tools:replace="android:allowBackup"
android:allowBackup="false">
...
</application>
Alike this one can disable auto-backup for debug builds - but keep it enabled for release builds.
Simply because disabling auto-backup for release builds might not be the intended outcome.
Based on #hungryghost's suggestion the I eventually implemented a solution
Problem:Shared preferences can be remembered by Android after app reinstall and blanket instructions in the manifest along the lines of android:allowBackup = "false" are not a solution.
So why not turn the problem into a solution on its own? Here is what I do
Check shared preferences for a build specific key.
If that key is not found I do two things
Clear out all shared preferences, context.deleteSharedPrefernces(filename)
Now create that build specific key
When I make app changes that require old preferences to be forgotten I simply change the build specific key.
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
The following link gives a brief description about package installation process in android.
http://java.dzone.com/articles/depth-android-package-manager
I'm curious to know how the UID of an app is determined during its installation based on set the permissions present in its manifest file.
Also there is the platform.xml (in /frameworks/base/data/etc directory for 4.0 ICS Source code)file which contains list of permissions with gid associated with them. The description says
The following tags are associating low-level group IDs with
permission names. By specifying such a mapping, you are saying
that any application process granted the given permission will
also be running with the given group ID attached to its process,
so it can perform any filesystem (read, write, execute) operations
allowed for that group.
In a similar way there is a list of high level permissions assigned to specific uid's as well.
My question is when an app is installed with permissions X,Y, Z how does its access specified is it from the mapping from this platform.xml
Also everytime the app is run does the mapping take place at every instant (that doesn't seem right from the initial design of android where the app permissions cannot be changed unless there is an update). So if that is the case where does it store saying this app should run with such and such access or such and such uid.
I hope I made my question clear, let me know if you need more information. I'm just trying to learn more on how the internals of the Android OS work.
Thanks
The UID of an application does not depend on the set of the requested permissions. In general case, during the installation PackageManager assigns a unique UID to an application from a set [FIRST_APPLICATION_UID; LAST_APPLICATION_UID] (actually, this process has slightly changed with the introduction of multi-user support):
The Android system assigns a unique user ID (UID) to each Android application and runs it as that user in a separate process.
What you are talking about is a limited set of GIDs (group ids) that is assigned to an application based on the permissions. For instance, to limit access of applications to the network interface a special patch has been added to Linux kernel, which allows a process to create net sockets only if this process has a special hardcoded GID. Thus, during the installation of an application if a user accepts the permission "android.permission.INTERNET", PackageManager assigns a special GID to this application (based on the values in platform.xml file). During the launch of this application, a process of this app is setgid'ed with the value. Thus, the process of application obtains a right to create sockets.
Other permissions are enforced on Android Framework level.
The permission requested by app only impact the GID but no the UID of the application.You may interested in check this article for all the uid and gid stuff.
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