背景
谷歌在Android M上推出了一项不错的新功能，允许您备份和恢复应用程序，甚至使用ADB，如this video所示 .
您似乎所要做的就是使用 adb shell bmgr 命令备份和恢复应用程序，如下所示：
备份：
adb shell bmgr fullbackup PACKAGE_NAME
恢复应用：
adb shell bmgr restore PACKAGE_NAME
它运作良好 .
问题
文档处于新的阶段，所以我无法找到有关这个新工具的一些问题的答案 .
我尝试了什么
在输入 adb shell bmgr 时，我得到了一些关于如何使用它的线索，但我找不到问题的答案 . 没有Android M的设备，而是一个模拟器，我猜它会有不同的工作方式 .
这是输入此命令时的内容：
用法：bmgr [备份|恢复|列表|传输|运行] bmgr备份PACKAGE bmgr启用BOOL bmgr启用bmgr列表传输bmgr列表设置bmgr传输bichr bmgr恢复TOKEN bmgr恢复TOKEN包... bmgr恢复包装bmgr运行bmgr擦除运输PACKAGE bmgr fullbackup PACKAGE ...'backup'命令为命名包安排备份传递 . 请注意，如果包实际上没有更改要存储的数据，则备份传递实际上将是无操作 . 'enable'命令启用或禁用整个备份机制 . 如果参数为“true”，它将被启用，否则将被禁用 . 禁用时，将不执行备份或还原操作 . 'enabled'命令报告备份机制的当前启用/禁用状态 . 'list transports'命令报告设备上当前可用的备份传输的名称 . 这些名称可以作为参数传递给'transport'和'wipe'命令 . 当前活动的传输用'*'字符表示 . 'list sets'命令通过当前活动的传输报告设备可用的每个恢复集的令牌和名称 . 'transport'命令将指定的传输指定为当前活动的传输 . 此设置在重新启动后保持不变 . 仅提供还原令牌时，“restore”命令将从当前活动的传输启动完整系统还原操作 . 它会将TOKEN参数指定的还原集传递给为该还原集提供数据的每个应用程序 . 当给定令牌和一个或多个包名称时，'restore'命令启动仅由TOKEN参数指定的恢复集中的那些给定包的恢复操作 . 它实际上与仅提供令牌的“恢复”操作相同，但将过滤器应用于要恢复的应用程序集 . 仅给出包名称时的'restore'命令根据RestoreSession.restorePackage（）方法使用的还原集选择算法，仅启动对该包的还原 . 'run'命令导致立即启动任何计划的备份操作，而没有通常的等待时间来将数据更改批处理 . 'wipe'命令导致给定包的所有备份数据从给定的传输存储中删除 . 给定应用程序执行的下一个备份操作将重写其整个数据集 . 此处使用的传输名称是“list transports”报告的名称 . 'fullbackup'命令为一个或多个包引入完整数据流备份 . 数据通过当前活动的传输发送 .
问题
我有几个问题：
-
假设我通过设备本身调用这些命令，它们会起作用吗？如果没有，他们会在root设备上工作吗？或者至少备份和恢复当前的应用程序（应用程序X备份和恢复本身）？
-
存储的备份在哪里？是否可以将它们存储到自定义路径中？也许甚至是PC之一？
-
是否可以将同一个应用程序备份到多个状态？例如，应用程序可以在其登录时具有备份，并在其配置了某些设置时进行备份 . 这样，您可以还原到每个备份 .
-
他们在上面的描述中写到“当前有效的运输” . 究竟是什么 ？它可以定制吗？
-
是否可以在所有应用上运行备份/恢复？或者我应该把所有应用程序的包裹？
-
似乎“fullbackup”立即进行备份 . “run”属性用于什么？或许这就是因为我使用模拟器？
2 回答
如果你还没有看到它们，这里是与自动备份相关的新功能的reference documents . 备份功能存在于先前版本中，并在guide中进行了描述 . 我和他们一起在KitKat上工作过 . 快速扫描后，M预览中的新功能似乎是：
自动每日备份
用于配置和控制备份中包含的内容的更多选项 .
您的大部分问题都集中在
adb shell bmgr工具上 . 它用于开发人员测试 . 在正常的设备使用中，当设备空闲，充电并连接到Wi-Fi网络时，备份每24小时自动完成 .备份是自动完成的，真的需要吗？
存储在用户的Google Cloud 端硬盘帐户中 . 不，不 .
由Google提供 . 不要这么认为 .
默认情况下，将备份所有应用程序 . 参考文档描述了如何限制包含的内容 .
除了新的自动备份功能外，应用程序还可以执行增量备份，如上面提到的指南中所述 . 提供
run命令用于测试，以允许开发人员强制立即激活增量备份处理 .嗨有Android开发人员 . 看起来我们有很多共同的兴趣（我在GcmNetworkManager上回答了你的问题） .
不幸的是，我不确定你的意思 . 我想你问的是，与模拟器相比，它们是否可以在真实设备上工作，答案是肯定的 . 某些东西在仿真器上运行的可能性很小，但在真实设备上却无法工作 - 通常情况就是这样 .
有两种类型的备份 - 旧的密钥/值备份由应用程序本身通过实现BackupAgent驱动，而从Android M到"full app data backup"这是框架为您提供BackupAgent实现的地方 .
在这两种情况下，备份数据都存储在Google的服务器上 . 没有办法将它们存储在自定义路径中，缺少编写自己的备份传输（这是OEM只能做的事情，或者是构建自己的自定义ROMS的人） .
不是 . 每个设备的每个应用程序都有一个“备份集” . 如果您进行恢复出厂设置，那么它将被视为新设备并具有不同的备份集 .
BackupTransport是特权（即/系统）应用程序，负责确定备份数据的存储位置 . BackupManager是操作系统的一部分，可在运行备份时进行管理，并从应用程序获取数据并将其传递给传输，然后传输将确定如何处理 . 操作系统可以知道数据应该去哪里，因此它会委托供应商提供的传输 . Transport是一个非常特权的应用程序，必须随系统映像一起提供 . 目前只有2种运输工具 - 本地'debug'运输工具和谷歌提供的运输工具 .
我假设你的意思是做adb shell bmgr . 不，没有办法做到这一点 . 但是，BackupManager中有隐藏的API，您可以调用它们以启动完全还原（例如，安装向导会执行此操作） . 由于API是隐藏的，因此您必须下载源代码并针对它进行编译（或使用反射） . 您还需要权限android.permission.BACKUP，注释@SystemApi . 我've never done this myself so I know it is theoretically possible but likely a huge headache as it'完全没有记录（它适用于OEM和其他自带设备的供应商） .
在android-M之前，只有键/值备份 .
两者都用于键/值备份流程 . 如果应用程序遇到了实现自己的BackupAgent（上面链接）的麻烦，它只能使用键/值备份 . 例如，许多系统组件执行此操作（例如，这是您的WiFi AP在设备之间进行恢复的方式） . 一些系统应用也会这样做（Gmail，谷歌启动器......），如果你运行的话
您将看到使用键/值备份的所有包的列表 . 您必须调用'bmgr backup p1 p2 etc'然后'bmgr run'的原因是b / c 'bmgr backup'命令将暂存要备份的软件包'in the future.'当您调用'bmgr run'时，这将手动启动备份传递 . 正如上面的帖子所说，它用于调试 .
如果你跑
在M设备上，您还应该看到使用完整的应用程序数据备份流程备份的应用程序列表，以及使用k / v备份的应用程序列表，这些应用程序将在未来进行“暂存”备份（此可能是空的，取决于你何时运行它） .
现在，
用于完整备份流程 . 然而，有一个问题 . 这两个（键/值备份和完全备份）是完全独立的，除了BackupManager使用键/值机制跟踪完整备份包的元数据（此元数据包括应用程序版本，签名，时间戳等内容） . 这就是你需要跑步的原因
在成功使用完整备份流之前，确保正确备份完整的应用程序数据元数据 .
不要认为仿真器与实际设备有任何不同 . 从理论上讲，它应该完全“模仿”真实设备 . 仿真器和物理设备之间应该没有区别，因此（AFAIK）没有“特殊”命令可以在仿真器上工作，而这些命令在真实设备上不起作用 .