一个字符串引起的大bug

最近我们在做一款给芯片升级的客户端，升级完成后需要重启，因为升级后芯片需要掉一次电才能正常使用。开发写好代码后就转到我这边测试了。具体的测试过程不说了，直接说这次遇到的问题：重启后芯片不能正常使用。

为了排查问题我们在升级完成后不使用程序触发重启，而是手动重启，发现芯片可以正常工作，那就说明是我们重启的方法不对，看了下开发的代码使用的重启方式是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”我们的芯片不会掉电呢，毕竟系统确实重启了，不解…….