【问题标题】:Android Backup service delayAndroid 备份服务延迟
【发布时间】:2015-11-24 10:36:28
【问题描述】:

我在当前应用中使用 Android 备份服务。 我在docs 上读到过

备份请求不会立即调用您的 onBackup() 方法。相反,备份管理器会等待适当的时间,然后对自上次执行备份后请求备份的所有应用程序执行备份。

有谁知道从dataChanged() 请求到实际备份操作大约需要多长时间?

或者,完全放弃 Android 备份服务并选择其他存储可能是一个不错的选择?

最好的问候!

【问题讨论】:

  • Android 备份不是同步数据的正确工具。据我所知,数据备份每天发生一次,并且仅在某些预定义的情况下发生,例如“在 wifi 上”、“电池已充电”等。
  • 我不确定,这是GDE在会议上的回答。
  • 感谢您的回答。那么适合做什么呢?顾名思义,我可以用它来存储例如用户偏好在那里,当用户重新安装数据或擦除应用程序时,它应该将它们恢复到以前的状态。但在你描述的情况下,看起来我不能为此目的使用它。
  • 你是对的,它假设备份你的数据 - 数据库,共享首选项,数据文件夹中的一些其他文件。但是限制是 25 Mb,当您达到限制时,备份将被自动禁用。现在操作系统决定何时进行备份,通常可以每天​​备份一次。
  • 好的,谢谢。我终于将备份移动到谷歌驱动器应用程序文件夹(我已经在应用程序中使用驱动器,所以这不是什么大问题)。可惜备份是这样工作的……

标签: android android-backup-service


【解决方案1】:

从调用 dataChanged() 到数据实际被推送到备份存储后端的确切时间将根据几个因素而有所不同:主要是连接性。设备运行的 Android 版本也很重要;延迟政策多年来一直在调整。完全延迟的原因是为了避免“不必要地”推送大量数据,用尽人们的每月数据配额,同时仍试图保持后端至少大部分是最新的,这样你就不会丢失大量数据如果您不小心将手机掉入河中或其他地方,则会发生变化。通常延迟长达一个小时,但从 Android M 开始它会更长(更像是 4 小时)。出于测试目的,您始终可以使用以下 adb 命令强制立即备份:

adb shell bmgr run

您还可以先通过对 bmgr shell 工具的不同调用来模拟您的应用调用 dataChanged():

adb shell bmgr backup com.myapps.packagename

(当然,只使用您应用的包名。)

您没有说明您的应用正在使用哪个数据路径——完整数据(Android M 中的新功能)或键/值(Android Froyo 中引入)。 dataChanged() 仅与较旧的键/值 API 相关。

正如上面 Viktor Yakunin 所指出的,备份不是同步的:备份系统的目标是在安装应用程序时无缝传送应用程序的数据,无论是在用户设置的新设备上,还是在卸载后在同一设备上重新安装应用程序。如果您想要的是数据交换机制,或者在多个设备上同时维护相同的数据,您应该查看同步管理器或其他类似的第 3 方工具。

【讨论】:

  • 感谢您的回答。感谢详细的解释:)我希望它在重新安装/数据清除时存储用户的数据,但是对于我的用例来说延迟太长了。但这是很好的体验:)
  • 您不能使用这种机制在“清除数据”操作中存储数据。当用户清除应用程序上的数据时,备份系统将强制备份新状态,即没有任何数据的状态。它处理卸载/重新安装情况,但不会在短时间内处理:如果用户在几个小时(或一天)内卸载应用程序,则数据不一定已备份 - - 但在这种情况下,用户基本上说他们首先对应用程序不感兴趣。
  • 哦,很高兴知道这一点。谢谢 :-) 我以为如果用户清除手机上的数据,稍后会恢复。
  • 是的——基本模型是在备份中维护设备数据状态的镜像。存在延迟,因为我们不想磨掉您的每月数据上限,在发生任何变化时立即将数据推送到备份,但是当事情赶上(通常是一夜之间)时,“稳定状态”是备份已经更新到匹配设备上的任何内容。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2018-10-07
  • 2013-08-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-01-14
  • 1970-01-01
相关资源
最近更新 更多