Android 使用EMMC FS的隐患
发布时间：2021-12-15 19:34:46 所属栏目：教程 来源：互联网
导读：由于项目一直使用老旧的Android 2.3.4，然后硬件加入了EMMC所以system和userdata的image格式也相应的由yaffs2变成了EXT4。 在调试过程中由此产生了两个问题： 一，image的生成问题：更改build/core下的Makefile。 以生成system.img.ext4为例，将原有的build-
|
由于项目一直使用老旧的Android 2.3.4，然后硬件加入了EMMC所以system和userdata的image格式也相应的由yaffs2变成了EXT4。 在调试过程中由此产生了两个问题： 一，image的生成问题：更改build/core下的Makefile。 以生成system.img.ext4为例，将原有的build-systemimage-target增加一行。相应的需要在device的BoardConfig.mk中根据EMMC分区定义BOARD_SYSTEMIMAGE_PARTITION_SIZE，定义tag TARGET_SYSTEMIMAGES_USE_EXT4作为开关。 ifeq ($(INTERNAL_USERIMAGES_USE_EXT),true) ifeq ($(TARGET_SYSTEMIMAGES_USE_EXT4),true) define build-systemimage-target @echo "Target system fs image: $(1)" $(call build-userimage-ext-target,$(TARGET_OUT),$(1),system,$(INTERNAL_USERIMAGES_EXT_VARIANT),$(BOARD_SYSTEMIMAGE_PARTITION_SIZE)) @echo "Using my script" $(MAKE_EXT4FS) -l $(BOARD_SYSTEMIMAGE_PARTITION_SIZE) -a system $(PRODUCT_OUT)/system.img.ext4 $(TARGET_OUT) endef else ## generate an ext2 image # $(1): output file define build-systemimage-target @echo "Target system fs image: $(1)" $(call build-userimage-ext-target,$(TARGET_OUT),$(1),system,$(INTERNAL_USERIMAGES_EXT_VARIANT),$(BOARD_SYSTEMIMAGE_PARTITION_SIZE)) endef endif # TARGET_SYSTEMIMAGES_USE_EXT4 else # INTERNAL_USERIMAGES_USE_EXT != true 二，init.rc脚本加载文件系统过程： 刚开始调试的时候进adb shell曾经报“exec - /system/bin/sh not found”错误，系统加载不成功。但是$(TARGET_OUT)目录下是完整的，因此应该是文件系统没有mount成功。init.rc中关于文件系统的片段如下： on fs # mount mtd partitions # Mount /system rw first to give the filesystem a chance to save a checkpoint mount yaffs2 mtd@system /system #mount yaffs2 mtd@system /system ro remount mount yaffs2 mtd@userdata /data nosuid nodev mount yaffs2 mtd@persist /persist nosuid nodev mount yaffs2 mtd@cache /cache nosuid nodev mount yaffs2 mtd@persist /persist nosuid nodev on emmc-fs wait /dev/block/mmcblk0p10 mount ext4 /dev/block/mmcblk0p19 /system rw barrier=1 chmod 0777 /system/bin/ext4check.sh # wait /dev/block/mmcblk0p11 exec /system/bin/sh -c "/system/bin/fixebr.sh mmcblk0" exec /system/bin/sh -c "/system/bin/ext4check.sh USERDATA /dev/block/mmcblk0p22" mount ext4 /dev/block/mmcblk0p22 /data nosuid nodev barrier=1 # wait /dev/block/mmcblk0p12 exec /system/bin/sh -c "/system/bin/ext4check.sh PERSIST /dev/block/mmcblk0p10" mount ext4 /dev/block/mmcblk0p10 /persist nosuid nodev barrier=1 # wait /dev/block/mmcblk0p13 exec /system/bin/sh -c "/system/bin/ext4check.sh CACHE /dev/block/mmcblk0p21" mount ext4 /dev/block/mmcblk0p21 /cache nosuid nodev barrier=1 可见fs和emmc-fs两段代表了两种不同的文件系统的加载，对比一下system/core/init/init.c在main函数中对fs的解析： action_for_each_trigger("init", action_add_queue_tail); action_for_each_trigger("early-fs", action_add_queue_tail); action_for_each_trigger("fs", action_add_queue_tail); action_for_each_trigger("post-fs", action_add_queue_tail); 可以看出这里并没有对emmc-fs端做任何处理，老旧的2.3.4呀。。。将其改成 action_for_each_trigger("init", action_add_queue_tail); action_for_each_trigger("early-fs", action_add_queue_tail); action_for_each_trigger("emmc-fs", action_add_queue_tail); action_for_each_trigger("post-fs", action_add_queue_tail); 后解决，这种hardcore方式还是不方便，可以采用宏定义或者运行时从Kernel读取配置来选择fs或emmc-fs的方式灵活配置。 另外还有一个小问题，/data/目录有时候会写不进去东西导致dalvik虚拟机不能把cache放进去一直启动不成功，在init.rc中把 mount rootfs rootfs / ro remount 这句从on post-fs的开始移动到init.rc的最后，这样就能保证先把/data分区里面必须的目录都建立好了再锁住。  （编辑：我爱故事小小网_铜陵站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330570号