孙尚香最暴力出装:android 2.1全手工App to SD成功

来源:百度文库 编辑:偶看新闻 时间:2024/05/05 03:59:20

 


 

手工App to SD的目的是为了消除不同机种和不同ROM之间的差异,一步一步人工确认app2sd各环节执行步骤的有效性,避免发生不必要诸如不能开机之类故障的麻烦。下面的步骤在Milestone 2.1上实现,均已milestone 2.1系统为例。参照说明,知其原理,可以自行沿用于其他机种。

一、准备工作:

1、学一点点android文件系统的知识:
milestone内存分为两个部分,一个部分是256M的程序运行内存,和App2SD无关,不讨论;我们关心的是另一部分,512M的机内闪存这部分,对于这部分我们应该把它理解为文件系统(FS),就如计算机的机内硬盘,而不要去理解为程序内存。
android是基于linux系统的,linux的文件系统挂载方式和微软文件系统(vfat、ntfs)挂在方式是不同的,linux文件系统不需要盘符,文件系统需要挂载到某个目录下面才能访问。最基本的那个目录是“/”,就是“根”。比如以微软的两个盘符为C:和D:的文件系统为例,假如我们把C:挂载到“/”上,还想访问D:中的数据,那么,我们就要用mkdir指令在“/”下面创造一个子目录,然后再用mount指令将文件系统D:,挂载到那个子目录上去。当然linux不用C:、D:这样的盘符,这样软件简介只是为了理解上比较简单。

回到milestone的512M内置文件系统上(所谓的机内闪存)。事实上,通过简单的分析手机中的一个重要的初始化文件init.rc,我们会发现,这机内的512M文件系统不是作为一个单一的文件系统来使用的,这一点,Root Explorer管理器工具(下面简称R.E.管理器)也能帮我们证实,点击/system看到的文件系统空间和点击/data看到的文件系统空间是不同的,但他们确实都处于机内闪存中。在init.rc里有这样几句

mount yaffs2 mtd@system /system
mount yaffs2 mtd@system /system ro remount #挂载yaffs2文件系统格式的 mtd@system 到目录 /system

mount yaffs2 mtd@userdata /data nosuid nodev #挂载yaffs2文件系统格式的 mtd@userdata 到目录 /data

上面几句明确的指出了两个文件系统,而且挂载的读写属性和Id设置均不同,App2SD要处理的部分是/data而不是/system,而系统核心程序主要是存放在“/”和“/system”中的,所以,只要不胡乱操作,一般是不会有什么副作用的。

android的应用程序(简称app),存放点有些差异,随系统一起安装的app,存放在/system/app目录中,这个是只读目录,没有root权限是不能卸载的;而用户自己安装的app,存放在/data/app中,App2SD要解决的就是/data空间不足的问题,用SD卡上格式化出来的ext2分区来替代/data/app、/data/dalvik-cache和/data/app-private等目录,从而达到扩展用户程序和VM cache等的空间。

2、一点点方便和一点点安全措施:
为了操作方便,我们需要两个工具,一个叫超级终端,一个就是上面提到的R.E.管理器,这两个工具都可以在电子市场里免费得到。这两个工具都需要root权限才能做我们需要的操作。
注意:这两个工具安装完之后,程序被存放在了/data/app目录下,因为过一会儿这个目录将被SD中的ext2文件系统挂载替代,假如出现挂载不成功,这两个程序将无法使用,为了给自己留后路,这里要做一步保险工作,将这两个程序移到/system/app下面去,这样做的目的是即便SD替换失败,还能用这两个工具来做一些必要的操作,从而恢复系统。
打开R.E.管理器,进入/data/app,找到刚才安装的超级终端,点中它长按,选拷贝,然后进入/system/app,注意这时候/system/app是以只读方式挂载的,在R.E管理器中点击挂载为读写方式按钮,即可粘贴超级终端程序到此目录下。
同样的方法拷贝R.E.管理器本身到/system/app下,这个操作可能使R.E.管理器crash,不过没关系,重启机器,R.E.管理器已成为系统自带工具了。

3、一个必须的工具:
busybox是一个android系统指令的扩展,由于App2SD需要用到不少linux的系统指令,busybox是必须安装的,这个工具对于DIY是很有用的,熟悉linux的朋友会觉得使用busybox很方便。
在电子市场里免费下载安装,注意安装好了以后是一个叫busybox-insteller的程序,必须运行它,运行busybox-insteller才是正真的安装busybox,同样需要root权限。

4、下载app2sd.rar包:
网上很多,搜索一下,机锋里应该就有。
这个包有专业的安装说明,其实是一个install.sh脚本自动工作,但脚本工作可能不如自己手工来的安全,建议有DIY能力的朋友自己动手,可以参考脚本上的指令,但为了安全,不要使用该安装脚本。

解压包,将这个包里的必须要用的重要文件拷贝到SD(fat32分区,通过USB用PC考入)卡中备用:
ext2.ko
mot_boot_mode

二、开始替换/data/app、/data/dalvik-cache和/data/app-private目录

1、重要的内核模块ext2.ko:
在开头的前提中我们提到,SD卡首先要被格式化好。这个网上有很多教程,就是SD被分为两个分区,一个vfat的,一个ext2的(ext2不要大于1.4G)。但是android的系统默认并不支持ext2文件格式,所以,如果要把SD卡的ext2文件系统顺利挂载到系统中,必须要给系统打补丁,ext2.ko就是解决这个问题的,它是一个内核选项模块,加载了这个模块,系统将能识别ext2文件系统格式,这点很重要,不能忽略。
用R.E.管理器,将ext2.ko文件拷贝到/system/lib/modules中。
打开超级终端,在超级终端中打入命令(注意不能输入错误,注意空格位置):
$$su ;分号(包含分号)后内容不需要输入,只是命令的解释。$$和后面的#号都是状态符,也不需要输入。su,超级用户,现在你是神了。
#insmod /system/lib/modules/ext2.ko ;加载内核选项模块ext2,让系统能够识别ext2文件系统格式

#lsmod ;验证ext2.ko是否被加载,如果被加载,可以看到ext2的加载信息

2、验证格式化过的SD卡文件系统是否正确:
打开超级终端,在超级终端中打入命令(注意不能输入错误,注意空格位置):
#cd /dev/block/ ;进入设备目录(文件系统在linux中一般为块设备)
#ls -l ;看看有哪些设备,一般会有/dev/block/mmcblk0p0
/dev/block/mmcblk0p1
/dev/block/mmcblk0p2
等,其中/dev/block/mmcblk0p1对应mmc设备上的第一个分区
/dev/block/mmcblk0p2就是我们要的第二个分区ext2分区

#mkdir /system/sd ;在/system目录下面创建一个子目录sd,用于挂载ext2文件系统
#mount -t ext2 /dev/block/mmcblk0p2 /system/sd
;将ext2文件系统/dev/block/mmcblk0p2挂载到/system/sd上
#busybox df -h ;检查文件系统是不是挂载成功,如果成功,会看到/system/sd文件系统挂载点,注意核对一下容量应该和SD卡上ext2分区的容量一致。
#cd /system/sd
#ls -la ;进一步确认文件系统是否成功,可以适当做些文件拷贝工作

3、乾坤大挪移:
到现在,新的ext2系统已经加载完毕,如果以上步骤有错,下面的工作就不要继续,检查一下SD卡的分区是不是正确。
如果前面的步骤无错,继续…
打开超级终端,在超级终端中打入命令(注意不能输入错误,注意空格位置):
#cp -rp /data/app /system/sd ;将原本/data/app目录全部拷贝到/system/sd下,完成后/system/app下会形成一个新目录/system/sd/app,其中内容和/data/app目录完全一样注意:这句和app2sd.rar包中的install.sh有些不同,加了一个p开关。linux系统的文件拥有者和读写权限管理比较严,加了p开关的目的是把把文件的用户属性和读写属性原封不动的挪移进新目录,因为当前操作者是root,而移到目录的拥有者是system用户。r开关是整个目录结构的拷贝
#cp -rp /data/dalvik-cache /system/sd ;同上,拷贝/data/dalvik-cache目录
#cp -rp /data/app-private /system/sd ;同上,拷贝/data/app-private目录

这是移花接木的步骤,就是把以前机器中用户自装的app和一些app过程信息搬到新的ext2文件系统下,以备文件系统的替换。
这时可以做一些必要的检查,在超级终端中打入命令(注意不能输入错误,注意空格位置):
#ls -l /system/sd/app ;核对拷贝完成情况
#ls -l /system/sd/dalvik-cache ;
#ls -l /system/sd/app-private ;

4、危险的替换:
到此为止,如果所有操作不是因为命令输入错误的话,不会对系统有任何的危害。但是,接下来的工作,有可能会造成系统不举等问题,需要非常小心,操作一步必须核对一步。

打开超级终端,在超级终端中打入命令(注意不能输入错误,注意空格位置):
#mv /data/app /data/app1 ;这个命令是让/data/app目录改名,因为我们接着要将/data/app目录链接到/system/sd/app目录
#su system ;这句话的意思是把自己变成system用户,因为/data/app目录的属于system用户而非root用户,接下来一句ln指令将已作为system用户发出
$ln -s /system/sd/app /data/app ;将/data/app作为一个link指向/system/sd/app目录。这是linux这样的类unix系统中最常用的形式,叫symoblic link,操作symoblic link等同操作实际目录。在早期的一些linux系统中甚至可以通过ln命令骗过文件权限设置而越权执行程序
$exit ;回到root用户

#mv /data/dalvik-cache /data/dalvik-cache1
#su system ;
$ln -s /system/sd/dalvik-cache /data/dalvik-cache
;这两步和上面的意思一样
$exit ;回到root用户

#mv /data/app-private /data/app-private1
#su system ;
$ln -s /system/sd/app-private /data/app-private
;意义同上
$exit ;回到root用户

需要注意的是,在一个一个击打命令的时候,系统可能会弹出一些报警,其原因是因为目录移动时一些服务类型的进程找不到目标目录。不需要在意,这不会有太严重的影响,直管完成上面几个操作。

操作完成后,还是用ls之类的命令去检查完成的结果是否可靠。
事实上,这些替换还不算要命,因为原本/data/app中的大多数app都不是致命的系统应用,都是用户自己安装的app。而接下来的一步去至关重要,千万小心。

5、引导的修改:
这步操作如果失误,可能会造成严重的后果。

以上所有的步骤都正确完成后,系统依然在掌控中,即便是上面的操作有些失误,系统也不会有太严重的问题,哪怕是重启后找不到/data/app等文件夹,也不会致命,可以通过超级终端等挽救(这点未经证实,最好也不要去求证,只是猜测。理论上/data/dalvik-cache操作失误会有点危险,因此,尽量不要失误)。

由于linux的insmod加载内核选项模块指令和mount文件系统挂载指令不是一劳永逸的,因此每次开机时都需要做这两项重要的工作,insmod加载ext2.ko模块和mount挂载SD的ext2分区。
打开超级终端,在超级终端中打入命令(注意不能输入错误,注意空格位置):
#mv /system/bin/mot_boot_mode /system/bin/mot_boot_mode.bin
;这是一种偷梁换柱的方法,系统在每次引导时都会执行mot_boot_mode这个文件,将它改名的目的是要用我们自己的同名文件来代替它,但是mot_boot_mode这个文件还是要保证它被以mot_boot_mode.bin文件名的形式在引导时被执行。
#ls -l /system/bin/mot* ;这句命令是重要的确认,确认这个文件被更名,如果确实被更名,ls后的显示应该不包含mot_boot_mode,而是显示mot_boot_mode.bin文件名。
确定文件被更名后,用R.E.管理器把app2sd.rar包中解压的文件mot_boot_mode拷贝到/system/bin/目录下,再提醒要小心,如果前面更名工作没有完成,拷贝动作将会覆盖掉原来系统自带的mot_boot_mode系统文件,这将铸成大错。
现在来看一下新的mot_boot_mode这个李鬼的脚本内容:
#!/system/bin/sh
export PATH=/system/bin:$PATH

#run original script
mot_boot_mode.bin

#mount ext2
insmod /system/lib/modules/ext2.ko
mount -t ext2 /dev/block/mmcblk0p2 /system/sd

最上面设定环境变量;中间那句很重要,就是让真李逵出来亮个相,所以,刚才那个条指令“mv /system/bin/mot_boot_mode /system/bin/mot_boot_mode.bin”中的“mot_boot_mode.bin”新文件名一定不能打错,不然引导就会出问题;最后两句我们前面手工打过,放在这里的意思就是让系统每次启动引导是都做一次。

最后一点点重要的收尾工作,同样很重要!!!在超级终端中打入命令(注意不能输入错误,注意空格位置):
#chmod 755 /system/bin/mot_boot_mode ;这句话是设置新mot_boot_mode的执行权限,要不然,如果没有X属性,系统是不会去执行它,同样会引起引导失败。

现在可以执行重启,关机重启,或者在超级终端里打入命令reboot重启。app2sd就此完成。

三、一些考虑:

替换mot_boot_mode问题:
这步比较有风险,鉴于在系统的根“/”中有个init.rc文件,是否可以利用。
在init.rc文件的“on boot”开关下面加入
insmod /system/lib/modules/ext2.ko
mount ext2 /dev/block/mmcblk0p2 /system/sd
init.rc中的语句是init来解析的,和标准linux指令有些差异,可以参考init.rc文档中指令的用法。
这是否有效,是否比替换mot_boot_mode安全,效果如何,可以进一步测试。

使用一天后,只有一个问题其他均正常。问题是:程序安装app中,安装过的程序不再记忆,不知道原因,目前用专用卸载工具弥补。