Android系统在开机时主屏幕应用Activity启动两次定位处理
本文于 322 天之前发表,文中内容可能已经过时。
记录定制的Android13系统中设置主屏幕应用后开机启动崩溃导致需要重新设置主屏幕应用,本文主要从问题产生,问题定位,问题解决如何思路展开描述。
背景
- 最近在开发的一款产品升级了芯片和系统,然后有用户反馈之前的A应用设置为主屏幕应用之后,断电开机自启动会出现需要重新设置主屏幕应用,一开始以为是系统问题,后面发现其他应用是正常的。所以需要定位是什么原因导致了这个问题。
问题产生
- A应用设置为主屏幕应用,断电重启或者使用adb reboot命令重启,A应用闪了下,然后从底部弹出了选择主屏幕应用弹窗。
问题定位
- 通过复现问题,观察发现A应用先是闪了下,那说明这个时候应用已经启动了,可能这个时候什么东西导致应用崩溃了,然后弹出了上面的选择主屏幕应用弹窗。
如何确定猜想
- 因为我们需要的日志是开机启动的,如果这个时候在应用中记录本地日志的话不能很好的定位,所以通过adb命令抓取当前一段时间的日志到本地,我们日志抓取的时候实际上是会把之前的时间日志也抓进来,命令:
adb logcat -v time -> log.txt
,通过日志搜索fatal:发现确实是应用崩溃了,报的是启动线程状态异常,什么意思,启动一次的线程再次启动会抛出下面的异常。
1 | --------- beginning of crash |
确定猜想
然后去看代码发现这个是放在Activity的onCreate去做启动,正常来说开机启动的话onCreate只会走一次,难道走了两次?加入日志观察,发现确实启动两次,那问题产生的原因是找到了。
那怎么解决这个问题,请继续阅读下一节内容。
问题解决
- 一开始以为是屏幕旋转导致的,开启启动发现每次自动旋转屏幕会默认打开,然后清单文件启动Activity增加了
android:configChanges="orientation|screenSize"
,测试发现没有作用。 - 没办法只能通过google,百度,bing搜索大法了,还真有类似问题,找到一个说是
MCC MNC等Configuration改变引起的 MCC(移动国家码)和 MNC(移动网络码)
问题的,也是增加配置android:configChanges="mcc|mnc"
,实际测试后发现也不是这个属性引起的,继续搜索,皇天不负有心人,找到一个说是启动Activity日志中带有Config changes=8
这个信息的,是需要加android:configChanges="touchscreen"
,测试后发现Activity启动一次,那就确定是这个属性变动导致的。 - 后面了解了下其实导致activity重新创建的属性还有很多,比如uiMode,locale等,如下配置
1
2
3
4
5
6
7
8
9
10android:configChanges=["mcc", "mnc", "locale",
"touchscreen", "keyboard", "keyboardHidden",
"navigation", "screenLayout", "fontScale", "uiMode",
"orientation", "screenSize", "smallestScreenSize"]
官方的解释是这样的:
Lists configuration changes that the activity will handle itself. When a configuration change occurs at runtime, the activity is shut down and restarted by default, but declaring a configuration with this attribute will prevent the activity from being restarted. Instead, the activity remains running and itsonConfigurationChanged() method is called.
大致意思也就是说:
那些被列举的属性configuration改变时activity是否保存自己的状态。当应用发生了configuration改变,默认情况下activity将关闭并重启自身,但是如果定义了这个属性,activity将不必重启,它将保持运行状态同时调用onConfigurationChanged()方法。也就是说当不配置android:configChanges="mcc|mnc"时,当mcc或mnc的值发生改变的时候,会重启activity,并且onConfigurationChanged()不会被调用
复盘
- 遇到系统相关日志需要看所有日志包括系统和应用的
- 搜索类似问题需要多找多试
- 解决问题固然是好的,但是我们需要知道它从哪里来,才能更好理解它,然后避免下次发生这个问题。