修改关机充电动画

说明

应该是2016年之前的记录，之前没有写文档记录的习惯，都是随手记录的txt文件，所以没有图片、格式等。甚至现在看来有些地方逻辑不通(可能还因为年少轻狂，有些偏颇的话语)，但是这些与现在的我不重要了，所以也不打算再复现、推理，重新编辑等，仅仅是在旧硬盘中发现，删除之前觉得可能还有点价值，记录下来吧。

1:充电动画是在/sbin/chargeonlymode这个文件中，以前用修改第一屏的方法替换过里面的充电图片，但是这样是不会动的画面。而官方关机画面中的数字电量其实一张包含数字和%的透明图片，可见处理方式是截取图片中部分显示，这种方式在coos2d中帧率的显示一样，至于具体对图片怎么截取和文字对应我还不清楚，很多recovery中也可以看到这样的应用，源码中有charger，但是至少秋叶随风提供的源码默认是不编译这个关机充电动画的。但是这个文件在一些recovery中有，比如秋叶随风的cm_recovery，从中取出这个文件，比如放在自己recovery或者boot的sbinmul或者根目录
2：编辑init.rc文件，寻找有没有on charger字样，意思就是充电事件触发的动作，官方boot是肯定定义好的
如下：
on charger
mount ext4 /dev/block/platform/msm_sdcc.1/by-name/system /system wait ro barrier=1
write /sys/module/rpm_resources/enable_low_power/L2_cache 1
write /sys/module/rpm_resources/enable_low_power/pxo 1
write /sys/module/rpm_resources/enable_low_power/vdd_dig 2
write /sys/module/rpm_resources/enable_low_power/vdd_mem 2
write /sys/module/pm_8x60/modes/cpu0/power_collapse/suspend_enabled 1
write /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/suspend_enabled 1
write /sys/module/pm_8x60/modes/cpu0/power_collapse/idle_enabled 1
write /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/idle_enabled 1
write /sys/module/pm_8x60/modes/cpu1/power_collapse/suspend_enabled 1
write /sys/module/pm_8x60/modes/cpu2/power_collapse/suspend_enabled 1
write /sys/module/pm_8x60/modes/cpu3/power_collapse/suspend_enabled 1
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor “userspace”
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 192000
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed 192000
write /sys/devices/system/cpu/cpu1/online 1
write /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor “userspace”
write /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq 192000
write /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed 192000
write /sys/devices/system/cpu/cpu2/online 0
write /sys/devices/system/cpu/cpu3/online 0
setprop sys.usb.config adb
class_start charger

是一些其他第三方boot或者recovery想要添加关机充电动画，recovery添加关机动画的情景应用与：把recovery刷到boot分区，这样存在的问题就是如果该分区是默认的启动分区，那么当有充电事件时，会一直处于emmc_appsboot.mbn定义的第一屏的界面。即使拔掉usb线也还是该界面。所以应该添加充电事件的处理。
把上面的内容拷贝到自己的init.rc文件中。
3：上面最后一行class_start charger意思是启动名字charger的服务。这个定义不在init.rc，在init.qcom.rc文件中：
service charger /sbin/chargeonlymode
class charger

把上面的代码拷贝到自己的init.rc文件，修改：
service charger /sbin/charger
class charger

注：如果是修改官方boot，直接在init.qcom.rc修改即可。一般第三方boot或者recovery不存在这个文件，而且即使存在这个文件，如果没有像这样在init.rc文件导入文件，如下
import /init.usb.rc
也是不会生效的。不过官方boot没有init.rc中导入这个文件，可能是init中定义了导入这些文件吧，或者${ro.hardware}这个变量是qcom，echo无法获取这个变量，getprop获取的是aries，后面确认确实是qcom，因为厨房查看的cmdline确实是qcom，所以实际上官方boot导入了。

3：这样当关机充电时就不时原来的动画了，出现charging换行??/100,这是因为缺少图片文件，在cm_recovery或者在源码/system/core/charger/images/拷贝图片到目录/res/images/charger/ 然后就能显示充电动画了。
注：至于为什么是??/100，是不是没有获取到电量不好判断，因为在有图片的模式下，是能粗略显示电量的，并不像官方一样有文字电量显示；用语言说就是有6张按编号排的图片第一张是电量0时，第二张表示电量的部分增长1/6，依次类推。如果电池电量高于第一张图片就从第2张到第6张循环显示。如果电量满了就停留在第6张。这就说明应该是可以读出电量的。目前只能解释为可能没有找到图片跳过了后面的电量检测的代码，因为自己没有看源码，只能推测。
不过有图片时充电状态led亮，一直红色，不会变化，没图片时led灯不亮，可能没有充电或者检测到电量？

4：图片的替换很简单，保证是png图片，大小不限，720x1280的图片可以全屏。唯一需要的就是最后图片数量不能比原来少，命名就用原来的名称替换比如battery_4.png，自己随便起名是不会成功的。

5：adb无法连接的问题
init.rc添加,我是加在on init里的

Always start adbd on userdebug and eng builds

write /sys/class/android_usb/android0/enable 1
start adbd

这样再执行adb device就找到设备了。

6：recovery关机状态下adb shell权限的问题：
官方boot在修改ro.secure=0后和关闭adb安全验证或者替换4.2版本之前的adbd均可以root启动，recovery却是shell权限，/sbin也没有权限访问，经测试发现关于这方面的处理应该在init中，因为替换官方的init后可以root启动。目前的解决办法：测试发现执行小米系统下的su文件可以获取root权限，好像不是所有版本都可以，因为另一个cm10.2的好像不能获取到。可以把小米系统中的su文件提取出来，路径/system/xbin/su，放置到recovry中，比如/etc/su，在init.rc中的添加
chmod 6777 /etc/su
解释：后三位不用解释，只要是第一位，查看su文件权限是"rwsr-sr-x"中的s是什么意思？
一般是可执行文件设置成这种形式
第一个s代表的是suid,Set UID：
他表示当其他的用户执行此命令时，可以取得和此文件的所有者一样的权限来取得系统资源
第而个s代表的是sgid，Set GID：
他表示当其他的用户执行此命令时，可以取得和此文件的属组一样的权限来取得系统资源
T或T（Sticky）：/tmp和
/var/tmp目录供所有用户暂时存取文件，亦即每位用户皆拥有完整的权限进入该目录，去浏览、删除和移动文件。

因为SUID、SGID、Sticky占用x的位置来表示，所以在表示上会有大小写之分。

SUID的代表数字是4，比如4755的结果是-rwsr-xr-x

SGID的代表数字是2，比如6755的结果是-rwsr-sr-x

Sticky的代表数字是1，比如7755的结果是-rwsr-sr-t

假如同时开启执行权限和SUID、SGID、Sticky，则权限表示字符是小写的：

-rwsr-sr-t

如果关闭执行权限，则表示字符会变成大写：

-rwSr-Sr-T
6=4+2，即同时设置UID和GID，所以6755也就是 rwsr-sr-x

0：指定文件类型，“0” 表示该文件是一个普通文件。符号是 “-” （所创建的文件绝大多数是普通文件）

所以：

0755、755、-rwxr-xr-x、rwxr-xr-x 表示的是同一个权限

06755、6755、-rwsr-sr-x、rwsr-sr-x 表示的是同一个权限

7：遗留问题：led灯不闪烁
官方boot倒是可以闪烁，只是也是红色，即使电量将满。
recovery使用cm10.2的内核不闪烁，长红，使用官方内核，可以闪烁，只是也是红色（说的官方内核指的是miui5-4.2.21版本的boot的内核）

米2官方boot，miui5-4.2.21版本的boot（实际可能不是这个版本，因为是自己修改几个版本通用的boot），用命令生成的boot不能开机也启动不了关机充电画面，第一屏卡
/media/ubuntu/home/dong/cm/cm10.2/out/host/linux-x86/bin/mkbootimg --kernel ./mmcblk0p19-zImage --ramdisk ./ramdisk-recovery.img --cmdline “console=ttyHSL0,115200,n8 androidboot.hardware=aries ehci-hcd.park=3 maxcpus=2” --base 0x80200000 --pagesize 2048 --ramdisk_offset 0x02000000 --output ./recoverycm.img
用厨房查看boot信息才发现原来cmdline和cm10.2的不一样。用下面的是正常的，并且cm10.2的内核也不能开机，第一屏后就是黑屏，还有一点亮度。原本以为androidboot.hardware应该是aries，没想到是qcom。
/media/ubuntu/home/dong/cm/cm10.2/out/host/linux-x86/bin/mkbootimg --kernel ./mmcblk0p19-zImage --ramdisk ./ramdisk-recovery.img --cmdline “console=null androidboot.hardware=qcom ehci-hcd.park=3 maxcpus=2” --base 0x80200000 --pagesize 2048 --ramdisk_offset 0x02000000 --output ./recoverycm.img

测试发现增加ttyHSL0,115200,n8也可以正常开机，即只要修改androidboot.hardware
而如果使用cm10.2的内核则该cmdline无效
/media/ubuntu/home/dong/cm/cm10.2/out/host/linux-x86/bin/mkbootimg --kernel ./mmcblk0p19-zImage --ramdisk ./ramdisk-recovery.img --cmdline “console=ttyHSL0,115200,n8 androidboot.hardware=qcom ehci-hcd.park=3 maxcpus=2” --base 0x80200000 --pagesize 2048 --ramdisk_offset 0x02000000 --output ./recoverycm.img

关于adb shell权限的问题：
ro.adb.secure=0 设置为0时表示禁用adb安全验证，即讨厌的4.2的提示是否允许adb连接，1是开启。
ro.secure=0 为0时代表内核root，执行adb shell默认root权限，1是shell组权限
ro.debuggable=1 为0代表禁用调试，1开启调试，这个只是应用层的设置，对于内核层无效，比如关机状态下没有启动应用层，即使设置为0依然可以使用adb