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
Related
I'm trying to remove some system apps from my android smartphone to debloat it. I use the following adb command: adb shell pm uninstall package.to.remove. But what if I will want to restore some of these apps? I can make a backup of the apk using adb pull my.package path/i/want. Then I can restore them using adb shell pm install package.to.install. I assume that the apps will be install as user app. So the questions are:
Will the system apps work even if they are installed as an user app?
Do I need to move the apks into the system partition?
If I remove some system apps and then I update my smartphone, will it break?
If you're using pm uninstall rather than pm uninstall -k --user 0 com.package.name, I'm asuming that you have root access. If that's the case, then its better/safer to use pm disable because you could enable them anytime with pm enable. If you're talking about some "non-necessary" apps, but not a system component, then yes you can uninstall them. But be careful doing that. Do your research on the app before uninstalling them, because it could lead you into boot loop. Make sure to keep backups of your apps if possible, if something goes wrong, you could copy them back again to their directories.
If you have root privilege, then yes, copying the apps back to their original place will retain their functionality. But if you try installing them without root, just as a user or using adb install, the apps will no longer be a system app, and most probably will be useless since they are already in the system, just disabled/uninstalled for the current user. A factory reset will reset all the apps like before. Hope this helps (:
I need to run a security test on one of our Android mobile applications.
It must not run if the device is rooted.
It should run as expected on non-rooted devices.
I have tested part 1 without issue and found it to work as expected.
However, I cannot seem to create an emulator using the AVD Manager that will not start with root access.
-Is there a command line method to reduce the emulator instance to non-rooted at startup?
-Failing that, is there a method to send an adb shell command (or other command line call) to reduce the permissions to the installed application?
Thanks!
Edit for #Fred.
I have opened the shell and changed it to the user id (uid) of the application under test. Note that in the image you can see the command, "adb shell su u0_a53" and then the next prompt includes the user, "u0_a53#generic_x86_64" as the returned shell and has the "$" indicating non-root access. However, when opening the application under test on the emulator, the application detects the device is rooted. What am I missing?
See attached image - click here
Yes, there is a way using SU to change super user to non root, see answer in this so question for directions:
https://android.stackexchange.com/questions/60599/how-to-get-non-root-access-on-emulators
As it turns out, my question was fundamentally flawed. The environment i'm trying to achieve could not be created with an emulator as part of the security test checks to see if the phone is in 'release' mode, in addition to looking for the presence of 'su'. After conferring with several other teams, I have decided to obtain a physical phone for testing this security restriction.
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.
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.
My application uses Google maps feature which needs Google Play services to be installed and enabled on the device.I wanted to test a case in which if Google play service has been disabled by user manually ask user to enable it so that application can work properly.SO i need to test my code against this case but I don't know how do I disable (not uninstall) Google play service on my phone and check if my code works properly.
Thanks
Go to your device's Settings --> Applications --> Tab "All" --> Google Play services and press the Disable button.
It may pop up a dialog asking for a confirmation, in which case just answer OK.
Go to Setting then security then device administrator then the android one deactivate that one then back to the settings homepage then applications all and you can deactivate it 😀
If Google play services is not installed as a system app you won't have the option to disable it in system app settings, in this case where it's installed as a user app you can use an app like Titanium back up pro or link2SD to disable/freeze it.
(Root Required) (Only tested on CM13 Note 10.1)
Close Play Store if open
Open ADB Shell (or Terminal on your rooted device) and type
cd /data/app/*vending*
mv base.apk base.apk.back
Disabling gapps
To disable all the apps that come with google's gapps you can use
pm disable <PACKAGE_NAME> (if rooted, run su once before this)
or
pm hide <PACKAGE_NAME> if not rooted.
Re-enabling gapps
To re-enable the apps use
pm enable <PACKAGE_NAME> (if rooted run su once before this)
and
pm unhide <PACKAGE_NAME> (if not rooted).
Enabling can also be done via the Settings > Apps > Show All apps > (tap app name) > Enable.
The commands should be run either from adb shell when connected via cable, or directly on the device from a terminal.
Here is a list of packages (extracted from open gapps mini):
com.google.android.apps.turbo
com.google.android.apps.wallpaper
com.google.android.apps.nexuslauncher
com.opengapps.wellbeingoverlay
com.google.android.tts
com.google.android.gm.exchange
com.google.android.googlequicksearchbox
com.opengapps.pixellauncheroverlay
com.google.android.syncadapters.calendar
com.google.android.gm
com.google.android.markup
com.google.android.packageinstaller
com.google.android.apps.wellbeing
com.google.android.calendar
com.google.android.soundpicker
com.google.android.ext.shared
com.google.android.setupwizard
com.google.android.apps.restore
com.google.android.onetimeinitializer
com.google.android.carriersetup
com.google.android.backuptransport
com.google.android.setupwizard
com.google.android.gms
com.google.android.apps.pixelmigrate
com.google.android.gsf
com.google.android.gms.policy_sidecar_aps
com.android.vending
com.google.android.ext.services
com.google.android.feedback
com.google.android.syncadapters.contacts
com.google.android.configupdater
com.google.android.partnersetup
❗️ Use at your own risk! Make sure you backup your data before doing this!
The list may vary depending on the version of android and CPU architecture.
I removed Google Play services from my Samsung phone as it was taking up a lot of space.
Read everywhere on forums by experts of serious problems and later realised these were just copy & Paste from Google itself.
I went ahead and just uninstalled it and got bonus of much better battery too.
As I had sync on, Playstore still updated apps. So I disabled auto sync to do so manually for which I want as I do not really want maps etc;
Youtube refused to start, so I now created a bookmark in my browser and access from there as anyhow I use my comp for downloads.
So if you have enough space just disable it in 'applications' or just remove it, your phone will function great - forget the experts comments/views on different forums which are copy and paste opinions from Google, you can always re-install if needed.
I have an LG-E400 smart phone, I always had problems with lack of memory. I uninstalled Google PLay Services today and everything is working fine. Maps, Youtube, Internet, everything working as normal.