In accordance with the documentation
Data backup is not guaranteed to be available on all Android-powered
devices.
How could I check in my code if it is supported or no?
I've tried to check what happens on my own device, but calling dataChanged says nothing except log message Backup pass but e=true p=false (explanation of the message is here). The same happens with adb shell bmgr backup my.package.name. I would like to inform my application user if it is not supported.
The backup APIs are available on any device starting with Froyo, but unfortunately some products historically have accidentally broken various aspects of the system's behavior. This should be much better as of Android M; there is considerably more focus on ensuring that backup/restore across the entire device population works well.
Related
I've just found an app that allows to disable Samsung apps without root, and in the background:
https://play.google.com/store/apps/details?id=com.hecorat.packagedisabler
And also this free one:
https://play.google.com/store/apps/details?id=com.ospolice.packagedisabler
How could this be? It doesn't even show a system-type alertDialog to ask the user if it's ok to disable the app. Did they find a flaw that allows doing so?
Is it only for Some Samsung apps? What about other apps and other companies? Is is possible there too?
Could the same mechanism be used for other operations? Like enabling apps?
I currently don't have a Samsung device, so I can't even check this app.
You can hide or unhide the apps provided you make your app as device owner with the api setApplicationHidden of DevicePolicyManager
Your app needs to be the device owner of the device. In order to become a device owner, you either need to do an NFC configuration or adb command shell. You can find a very well written blog by Florent here.
However, there is a new method of getting your application to become a device owner starting with Android Marshmallow. With a lot of limitations though. You have to be an EMM provider and your client has to have a google business or edu licensing for this to work.
There is no application on the google play store that allows your app to become device admin. As a device owner you have a lot of things you can control on the device and hence, I believe Google may not want to provide this kind of control without proper safeguards.
With regards to Samsung Devices, they provide their knox sdk as mentioned with other answers here which gives you access to certain APIs that are not allowed via stock Android.
background
Google has introduced a nice new feature on Android M that allows you to backup and restore apps, even using ADB , as shown on this video .
It seems all you have to do is use the adb shell bmgr command to backup and restore apps, as such:
backup:
adb shell bmgr fullbackup PACKAGE_NAME
restore an app:
adb shell bmgr restore PACKAGE_NAME
And it works well.
The problem
The docs are quite in their new phase, so I can't find answers to some questions about this new tool.
What I've tried
When typing the adb shell bmgr, I get some clues about how to use it, but I can't find the answers to the questions. Not having a device with Android M , but an emulator instead, I guess it will work differently.
Here's what's written when typing this command:
usage: bmgr [backup|restore|list|transport|run]
bmgr backup PACKAGE
bmgr enable BOOL
bmgr enabled
bmgr list transports
bmgr list sets
bmgr transport WHICH
bmgr restore TOKEN
bmgr restore TOKEN PACKAGE...
bmgr restore PACKAGE
bmgr run
bmgr wipe TRANSPORT PACKAGE
bmgr fullbackup PACKAGE...
The 'backup' command schedules a backup pass for the named package.
Note that the backup pass will effectively be a no-op if the package
does not actually have changed data to store.
The 'enable' command enables or disables the entire backup mechanism.
If the argument is 'true' it will be enabled, otherwise it will be
disabled. When disabled, neither backup or restore operations will be
performed.
The 'enabled' command reports the current enabled/disabled state of
the backup mechanism.
The 'list transports' command reports the names of the backup
transports currently available on the device. These names can be
passed as arguments to the 'transport' and 'wipe' commands. The
currently active transport is indicated with a '*' character.
The 'list sets' command reports the token and name of each restore set
available to the device via the currently active transport.
The 'transport' command designates the named transport as the
currently active one. This setting is persistent across reboots.
The 'restore' command when given just a restore token initiates a
full-system restore operation from the currently active transport. It
will deliver the restore set designated by the TOKEN argument to each
application that had contributed data to that restore set.
The 'restore' command when given a token and one or more package names
initiates a restore operation of just those given packages from the
restore set designated by the TOKEN argument. It is effectively the
same as the 'restore' operation supplying only a token, but applies a
filter to the set of applications to be restored.
The 'restore' command when given just a package name intiates a
restore of just that one package according to the restore set
selection algorithm used by the RestoreSession.restorePackage()
method.
The 'run' command causes any scheduled backup operation to be
initiated immediately, without the usual waiting period for batching
together data changes.
The 'wipe' command causes all backed-up data for the given package to
be erased from the given transport's storage. The next backup
operation that the given application performs will rewrite its entire
data set. Transport names to use here are those reported by 'list
transports'.
The 'fullbackup' command induces a full-data stream backup for one or
more packages. The data is sent via the currently active transport.
The questions
I have a few questions:
Suppose I call those commands via the device itself, will they work? If not, will they work on a rooted device? Or at least backup&restore the current app (app X backups&restores itself) ?
Where are the backups being stored? Is it possible to store them into a customized path ? Maybe even the one of the PC ?
Is it possible to backup the same app into multiple states? For example, an app could have a backup for when it has logged in, and a backup for when it has some settings being configured. This way, you could restore to each of those backups.
They write in the above description about "currently active transport" . What is it exactly ? Can it be customized?
Is it possible to run a backup/restore on all apps? Or should I put the packages of all apps?
It seems the "fullbackup" does the backup right away. What does the "run" attribute used for? Or maybe that's all because I use an emulator?
If you haven't already seen them, here are the reference documents for the new features related to auto backup. Backup capabilities existed in previous versions and are described in this guide. I've worked with them on KitKat. After a quick scan, it appears that the new features in the M Preview are:
Automatic daily backup
More options for configuring and controlling what is included in the backup.
Much of your question focuses on the adb shell bmgr tool. That it for developer testing. In normal device use, the backup is done automatically every 24 hours, when the device is idle, charging, and connected to a Wi-Fi network.
Suppose I call those commands via the device itself, will they work?
With the backup being done automatically, is there really a need for that?
Where are the backups being stored? Is it possible to store them into
a customized path ? Maybe even the one of the PC ?
Stored to the user's Google Drive account. No. No.
They write in the above description about "currently active transport"
. What is it exactly ? Can it be customized?
Provided by Google. Don't think so.
Is it possible to run a backup/restore on all apps? Or should I put
the packages of all apps?
By default, all apps are backed up. Reference docs describe how to limit what is included.
It seems the "fullbackup" does the backup right away. What does the
"run" attribute used for? Or maybe that's all because I use an
emulator?
In addition to the new auto backup capability, an app can perform incremental backups, as described in the guide mentioned above. The run command is provided for testing, to allow a developer to force an immediate activation of the incremental backup processing.
Hi there android developer. It seems like we have a lot of shared interests (i answered your questions on GcmNetworkManager).
Suppose I call those commands via the device itself, will they work? If not, will they work on a rooted device? Or at least backup&restore the current app (app X backups&restores itself) ?*
Unfortunately I am not sure exactly what you mean. I think you are asking if they will work on a real device as compared to an emulator and the answer is yes. There is little chance that something will work on an emulator but not work on the real device - usually it is the other way around.
Where are the backups being stored? Is it possible to store them into a customized path ? Maybe even the one of the PC ?*
There are 2 types of backup - the older key/value backup which is driven by the application itself by implementing a BackupAgent, and as of Android M there is "full app data backup" which is where the framework provides the BackupAgent implementation for you.
In both of these cases the backup data is stored on Google's servers. There's no way to store them in a customized path, short of writing your own backup transport (which is something that only OEMs can do, or people who build their own custom ROMS).
Is it possible to backup the same app into multiple states? For example, an app could have a backup for when it has logged in, and a backup for when it has some settings being configured. This way, you could restore to each of those backups.*
No. There is one 'backup set' per application per device. If you do a factory reset then it's considered to be a new device and will have a different backup set.
They write in the above description about "currently active transport" . What is it exactly ? Can it be customized?*
The BackupTransport is the privileged (i.e. /system) app that is responsible for determining where the backup data is stored. The BackupManager is part of the OS and manages when backups are run and takes the data from the application and passes it to the Transport, which then determines what to do with it. The OS can't take responsibility for this b/c it doesn't know where the data is supposed to go, so it delegates to a vendor-supplied Transport. The Transport is a very privileged app that must be shipped with the system image. Currently there are only 2 transports - the local 'debug' transport, and the Google-provided transport.
Is it possible to run a backup/restore on all apps? Or should I put the packages of all apps?*
I assume you mean by doing adb shell bmgr. No there's no way to do this. However there are hidden APIs in the BackupManager that you can call in order to initiate a full restore (the Setup-Wizard does this for example). Because the APIs are hidden you would have to download the source and compile against it (or use reflection). Also you need the permission android.permission.BACKUP which is annotated #SystemApi. I've never done this myself so I know it is theoretically possible but likely a huge headache as it's completely undocumented (it's meant for OEMs and other vendors that ship their own devices).
It seems the "fullbackup" does the backup right away. What does the "run" attribute used for? Or maybe that's all because I use an emulator?*
Prior to android-M there was only key/value backup.
adb shell bmgr backup <PACKAGE..>
adb shell bmgr run
Are both for the key/value backup flow. An app can only use key/value backup if they went to the trouble of implementing their own BackupAgent (linked above). For example, a lot of system components do this (this is how your WiFi APs are restored across devices, for example). Some system apps do this as well (Gmail, the Google launcher,..) in fact if you run
adb shell dumpsys backup
you will see a list of all the packages that use key/value backup. The reason that you have to call 'bmgr backup p1 p2 etc' and then 'bmgr run' is b/c the 'bmgr backup' command will stage the packages to be backed up 'in the future.' When you call 'bmgr run' this manually kicks off the backup pass. As the post above says, it is meant for debugging.
If you run
adb shell dumpsys backup
On an M device you should also see the list of apps that have been backed-up using the full app data backup flow, as well as the list of apps using k/v backup that are 'staged' for backup in the future (this might be empty depending on when you run it).
Now,
adb shell bmgr fullbackup <PACKAGE..>
is for the full backup flow. However, there is a catch. The two (key/value backup & full backup) are completely independent, except that the BackupManager keeps track of metadata for the full backup packages using the key/value mechanism (this metadata includes things like app version, signature, timestamps, etc). This is why you need to run
adb shell bmgr run
to ensure that the full app data metadata is correctly backed up, before you can successfully use the full backup flow.
Don't think of the emulator as any different from an actual device. In theory it is supposed to exactly 'emulate' the real device. There should be no difference between the emulator and the physical thing, so (AFAIK) there are no 'special' commands that work on an emulator that won't work on a real device.
Background
I wish to store and restore some settings and other values for an app i'm working on.
The problem
As it turns out, Android already has a nice feature called "BackupAgent".
However, it also seems it's not supported on all devices:
Data backup is not guaranteed to be available on all Android-powered
devices
it's not an API issue (though it is supported only from 2.2), but a manufacturer/carrier issue:
The backup transport is the client-side component of Android's backup
framework, which is customizable by the device manufacturer and
service provider. The backup transport may differ from device to
device and which backup transport is available on any given device is
transparent to your application. The Backup Manager APIs isolate your
application from the actual backup transport available on a given
device—your application communicates with the Backup Manager through a
fixed set of APIs, regardless of the underlying transport.
The question
Is there another free alternative to store & restore data on Android into the cloud?
I'm having this same problem - as found in the google developer group. I quote what it is a very detailed explanation by Chris Grebeldinger (original author).
"In the documentation:
http://developer.android.com/guide/topics/data/backup.html#Testing
It recommends testing backup/restore of your application by:
installing your app
make sure backup/restore is enabled
changing some data and calling dataChanged()
forcing bmgr to run a backup pass
uninstall the app
re-install the app and check if your data was restored
All seems well until step 4, when I see this in the log:
V/BackupManagerService( 306): removePackageParticipantsLocked: uid=10078 #1
V/BackupManagerService( 306): Removing backed-up knowledge of com.example.app
And then for step 5:
V/BackupManagerService( 306): restoreAtInstall pkg=com.example.app token=21
V/BackupManagerService( 306): No restore set -- skipping restore
So apparently backed up data is destroyed when an app is uninstalled, which means the official testing workflow can't possibly work right? What's the best way to test this?"
Has anybody managed to run and test this sample correctly?
Thanks again to Chris Grebeldinger which kindly answered my reply to his original post in the google android developer group.
How it does work:
Install the app in device A.
Set any data or preferences in device A.
Force a backup on device A. (Using adb shell bmgr backup [app_name], adb shell bmgr run).
Grab a second device B.
Perform a factory reset on device B.
Once reset, install the app again.
The restore operation should be successful.
What annoys me is that the "steps" as shown on the Google Android documentation which appear to be quite detailed decided to omit what it appears to be a necessary and compulsory steps.
As Chris mentioned on his reply, I hope this helps other people who find the same problem.
Thanks.
EDIT:
After further testing with different devices, it appears that the whole backup/restore process can vary from manufacturer and device. I could test the sample app using Google's document approach i.e. by uninstalling and installing using a nexus 7 - just by a coincidence. So, my advice would be not to expect the same behaviour and consistency during your tests.
Try using the emulator for testing purposes. Nexus 5 with API 22 worked for me just by uninstalling and installing the app.
Full process:
Enable backup by adb: bmgr enable true
Set local transport:
bmgr transport android/com.android.internal.backup.LocalTransport
Run your app and prepare for backup
Run backup: bmgr backup <package> & bmgr run
Uninstall app from emulator
Install the app again - restore should happen automatically
Tip: lookup logcat for "backup" activities
I have Users with rooted Android 2.2+ smartphone devices.
Whenever any on-device App accesses the device's Contacts List, Microphone or Camera resource, I want to Suspend that App, pop up a warning message to the User, and let the User decide whether to Abort or Continue.
Even though at App install-time the User might have (blindly) granted those Apps permission to access those Resources.
So, I want to write an Android System Service to continuously scan the File Descriptors (or whatever) representing the Contacts List, Microphone and Camera.
If any other application or service/process/thread attempts to open any of the above file descriptors, I suspend it and pop up a Toast message to the User, something like:
"Application "CHESS" is trying to access the CAMERA!!! Close the app, or Continue?";
I could find absolutely nothing on the Android SDK or NDK which would help me achieve my above goal.
Not even a quick-and-dirty-and-dangerous Linux command approach like "./data/lsof -w | grep audio" inserted and run on the device was of any help whatsoever -- I don't know what precise Android resource names to grep for, and moreover the Resources' file descriptors seem to be open all the time whether they are being accessed or not!
Thank you, any advice would be greatly appreciated.
I would agree with the previous posts saying it might not be possible. But if you were deploying your own kernel, then this has a good suggestion thread here: Android Kernel modifying
also this thread here is along similar low level hooking that you want: http://groups.google.com/group/android-developers/browse_thread/thread/821e5a413f0014d9
Here is how to write a driver for android: http://www.kandroid.org/online-pdk/guide/display_drivers.html. Possibly you need to write a driver that is generic and just replaces the existing drivers that you want. that driver would then point to a backed up location of the old drivers, effectively wrapping the old driver. This way you should hopefully keep a generic driver that you write, and the same behavior and nice abstraction the manufacturer drivers provide.