一个字符串引起的大bug
来源:互联网 发布:手持身份证照片 软件 编辑:程序博客网 时间:2024/05/17 05:58
最近我们在做一款给芯片升级的客户端,升级完成后需要重启,因为升级后芯片需要掉一次电才能正常使用。开发写好代码后就转到我这边测试了。具体的测试过程不说了,直接说这次遇到的问题:重启后芯片不能正常使用。
为了排查问题我们在升级完成后不使用程序触发重启,而是手动重启,发现芯片可以正常工作,那就说明是我们重启的方法不对,看了下开发的代码使用的重启方式是PowerManager中的reboot方式。我们准备换一种重启方式,使用命令,但是我印象中5.0之后应用层是拿不到su权限的,于是我就看了下之前写的一个测试工具中的重启方式,发现果然是拿不到su权限的。于是我们准备使用另一种方式Intent,等等,这种方式最终还是会走到PowerMnagerService中,和PM的方式一样。怎么办?到此我们已经无计可施了,我们再次回到原点,认真看了下开发的代码。
((PowerManager)mContext.getSystemService(Context.POWER_SERVICE)).reboot(“111”)
有亮点是不是? “111”是什么鬼? 我们看了下源码,源码中是这样解释的,reason参数是传递给内核的,让内核知道我们要重启到那种模式,或者直接为空也行。
/**
789 * Reboot the device. Will not return if the reboot is successful.
790 *
791 * Requires the {@link android.Manifest.permission#REBOOT} permission.
792 *
793 *
794 * @param reason code to pass to the kernel (e.g., “recovery”) to
795 * request special boot modes, or null.
796 */
797 public void reboot(String reason) {
798 try {
799 mService.reboot(false, reason, true);
800 } catch (RemoteException e) {
801 }
802 }
难道就是因为参数传递的不正确导致的,为了证明这点,我们再次进行了升级,并在升级后使用adb reboot 111 来重启,果然,重启完成后芯片不能正常工作,到此原因已经找到了。
到底reason应该传什么呢? 我们通常知道的reboot 后面可以跟的命令有bootloader、recovery以及persist.sys.safemode(安全模式),显然这三种都不是我们想要的,于是我们又进行了一次升级,然后使用adb reboot来重启,这次芯片可以正常工作。我们把代码中的“111”给移除了不传递任何参数,然后试了一次,芯片也可以正常工作。问题到这算是解决了,但是为什么传递“111”我们的芯片不会掉电呢,毕竟系统确实重启了,不解…….
- 一个字符串引起的大bug
- 字符串拷贝引起的bug
- memcpy引起的一个bug
- 一个分号引起的bug
- 一个BUG引起的思考
- JDK6的Random和System.nanoTime()引起的一个“大”bug
- GetTickCount引起的一个诡异bug
- 一个由sscanf函数引起的bug
- 一个类型转换引起的Bug
- 一个由于spring事务引起的bug
- 一个由于全局变量引起的BUG
- Loader Lock引起的一个Bug
- 由一个bug引起的关于list的思考
- unsigned引起的bug
- typedef引起的bug
- php中post键值过多引起的一个bug
- 一个不良编程习惯引起的怪异bug
- mediaserver 异常挂掉引起的一个BUG
- 算是开端吧
- PAT1083
- HTML5游戏的崛起及营销未来
- Oracle中的函数和存储过程--真实项目示例
- Windows8,7和Office2013,2011破解激活工具
- 一个字符串引起的大bug
- eclipse PyDev 字符集编码设置的3种方法
- Solr全量索引
- AngularJs渲染完毕后执行指定操作
- TFS 用户的配置,修改计算机名后的处理
- 关于加载器ld-linux-armhf.so.3
- android之service组件使用总结
- Hadoop:HDFS的特性
- html jq 操作