我的
annotator generator用于制作Android Web浏览器应用程序,为中文文本添加发音辅助工具.根据您想要的地区发音,可以使用不同种类的发音辅助设备(例如普通话拼音,广东话Sidney Lau,温州……)为了节省旧Android手机上的存储空间,我们将每个辅助设备作为单独的应用程序发布,因为大多数用户不会需要不止一个.但是在2018年3月初受欢迎的请求我添加了一个书签功能,并在我的AndroidManifest.xml的< manifest标签中愚蠢地添加了一个android：sharedUserId属性,以允许不同版本的应用程序分享他们的书签以获得少数权力用户在不同类型的发音辅助之间切换. 但是我们已经拥有大约5,000名用户,并且一些(但不是全部)用户开始报告他们现在无法更新应用程序.当然Android做了它常用的事情,只是告诉他们有一个问题没有提供任何可能让我知道我做错了什么的技术信息,所以我只是回复报告说尝试卸载并重新安装或清除Play商店应用程序的数据,也就是在我终于遇到一个人,其旧的三星Galaxy S2(Android 4.1)没有更新,我能够将它连接到我的开发盒并观看adb日志和锯这个：
04-04 21:54:58.653: W/PackageManager(2127): Package org.ucam.ssb22.pinyinwol shared user changed from <nothing> to org.ucam.ssb22.annogen; replacing with new
04-04 21:54:58.708: I/BootTime(2127): Fail Safe scanning for:/mnt/asec/org.ucam.ssb22.pinyinwol-1/pkg.apk
04-04 21:54:58.708: W/PackageManager(2127): Package couldn't be installed in /mnt/asec/org.ucam.ssb22.pinyinwol-2/pkg.apk
进一步搜索表明,一般的共识是你永远不应该将一个sharedUserId属性添加到已经发布的应用程序中,或者用户将获得INSTALL_FAILED_UID_CHANGED(尽管该字符串不在这些特定日志中;我认为这取决于Android版本) .
但我现在不能仅删除sharedUserId,因为一些新用户在过去5周内重新安装了应用程序,并且可能其中一些用户还在Android版本上无法应对更新期间更改的sharedUserId.
我很乐意告诉Play商店“如果任何用户的设备无法应对更新此应用程序,请卸载旧版本并为其全新安装”. (或者甚至“请无条件地将此更新作为全新安装”.)但是在AndroidManifest或Play Store控制台上似乎没有任何方式可以说.我发现了解决方案涉及应用程序本身的代码,但我的问题是我的应用程序将无法安装,直到数据被擦除,我无法告诉用户擦除数据,除了通过发布建议我在任何地方可以并且希望他们看到它 – 很可能不会.
我能想到的唯一解决方案是使用sharedUserId和sharedUserId交替推出更新,在每个更新之间等待一段时间,希望受影响的设备至少安装两个更新中的一个.这当然会牺牲共享书签功能(除非我首先使用除sharedUserId之外的某种机制重新实现它)并且它不是一个非常优雅的解决方案.所以我发布这个问题是希望有人可以在我陷入这个混乱之后建议我应该做些什么.
最佳答案 我尝试了以下解决方法：
>在星期一发布带有sharedUserId的版本,带有额外的启动代码来检查日期和(a)如果它在发布后的7天内,它说下周的更新可能是一个问题,但不要担心并等待以下一周,(b)如果它在发布后的14天内,它表示本周的更新可能是一个问题,但不要担心,等待下周的.
>接下来的星期一,发布没有sharedUserId的版本,设置工作几周然后完全停止工作,告诉用户他们必须卸载并重新安装应用程序.
>之后的星期一,发布一个版本,其中sharedUserId恢复正常.
我的计划是,这将导致(a)设备不关心sharedUserId的用户将通过所有3个版本自动升级,除了版本1的消息(在他们的情况下是假的)之外没有注意到任何东西,(b)设备卡住的用户在pre-sharedUserId版本上将获得版本2,并且随后将告知卸载并重新安装版本3是当前版本,(c)其设备卡在post-sharedUserId上的用户将获得版本1和3,并且将仅注意到在第2版本周期间“未能更新”消息,他们在版本1中被警告过.
根据Play商店的统计数据,实际发生的事情是：
>在第1周结束时,超过55％的活跃用户被卡在我设置sharedUserId之前发布的最新版本上,加上早期版本的20％(因此超过75％被“落后”).大约15％的活跃用户下载了警告第2周更新可能失败的版本.
>在第2周结束时,“我的sharedUserId陷入困境之前的最后一个版本”的数字从我的活跃用户的55％下降到16％.大约45％的活跃用户已升级到非sharedUserId第2周版本(如果第3周的版本未能自动替换,则设置为告诉他们重新安装的版本),另有12％的用户仍然在第1周版本并被告知不要担心.我有大约19％的人坚持使用早期版本(低于20％).我开始怀疑19％的人大多数都禁用了他们的更新.
>在第3周中途,在第2周版本开始告诉用户重新安装后的第1天,我在第2周的版本中有44％(并被告知他们必须重新安装以进行更新,所以至少现在他们知道了),16％第3周,13％在“最后版本搞砸之前”,仍然是旧版本的尾巴.
所以这不是一个完美的答案,但在我的情况下,它至少帮助我告知超过四分之三的受影响用户他们现在需要重新安装,这比他们都不知道的要好.
