跪求安卓2.3.6酷比ks306手机ROM包ROOT工具

Posted 2023-04-11

跪求安卓2.3.6酷比ks306手机ROM包ROOT工具

设备型号：KS306 酷比（koobee）
电池电量：52%
固件版本：2.3.6
WiFi状态：关
是否ROOT：未ROOT
分辨率：320*480
制作团队：未知
序列号：0123456789ABCDEF
IMEI：866351010174290
IMSI：460013200320007
MAC地址：c8:ae:9c:35:f1:4a
内部版本号：2.3.6
基带版本：MAUI.11AMD.W11.37.SP.V19.F2, 2012/06/26 20:11
内核版本：hsimobile13_gb-user 2.3.6 GRK39F eng.kelven.1356165479 test-keys

目前在android手机上，还没有统一的获取
ROOT的方法，各个机型在获取ROOT权限
时的操作要点也不尽相同。目前主流的一键
ROOT软件有
Z4ROOT,UniversalAndroot,visionaryplus,GingerBreak
等，到网上搜索下载这些软件后安装，按照
提示操作就可以了。
以下是比较常见的一种方法：
1.下载upd-1.zip压缩文件（到网上找），
不需要解压，放入sd卡中。
2.关机，同时按住"home+开机键"开机。
3.出现蓝色的英文字母，用音量键选择到第
二个（apply update from sdcard），按
home键确认。在sd卡的目录中找到你刚才
放入的upd-1.zip并按home键。
4.稍等会回到原来的界面，选择第一个
（reboot system now），按一下home
键。
5.重启后，root就成功了。
希望这些对你有帮助。
不管怎么刷机都是有风险的，当然选择是你
自己做出的所以后果也是自负。
root后手机拥有更大权限，可以装一些需要
高权限的软件，也可以删除一些系统没用的
软件，更可以app2SD，释放出手机自带的
那点可怜的存储，让手机运行速度更快。
豌豆荚这个软件还不错，但它是一款在电脑
上运行的软件，所以打开你的电脑连上数据
线吧！
　无法一键Root可以由于以下原因所导
致：
　　1、手机未解锁：
　　有些手机在出产的时候，官方(例如htc
和索爱等)做了对手机Rom保护，这会导致
Root的失败，这时候需要先去手机的官方网
站下载解锁工具，对手机进行解锁。解锁之
后，再用腾讯手机管家(PC版) for Android
进行Root，应该就可以Root成功了。
　　2、特殊的Rom：
　　由于有些设备的Rom和系统环境的特殊
性，腾讯手机管家(PC版) for Android暂时
是还不支持部分机型Root的。
如果对你有帮助希望不吝给分，谢谢！ 参考技术A 不用找了，没有的，就算你破解了，也没有多大内存给你运行的！！ 参考技术B 用腾讯的电脑版root,再升级su二进制就行了

如何打包安卓手机Zip升级包？如何签名？不换Recovery，用官方Recovery

　　通过分析update.zip包在具体Android系统升级的过程，来理解Android系统中Recovery模式服务的工作原理。
我们先从update.zip包的制作开始，然后是Android系统的启动模式分析，Recovery工作原理，如何从我们上层开始选择system update到重启到Recovery服务，以及在Recovery服务中具体怎样处理update.zip包升级的，我们的安装脚本updater-script怎样被解析并执行的等一系列问题。分析过程中所用的Android源码是gingerbread0919（tcc88xx开发板标配的），测试开发板是tcc88xx。
　　一、 update.zip包的目录结构
|----boot.img
　　|----system/
　　|----recovery/
　　`|----recovery-from-boot.p
　　`|----etc/
　　`|----install-recovery.sh
　　|---META-INF/
　　`|CERT.RSA
　　`|CERT.SF
　　`|MANIFEST.MF
　　`|----com/
　　`|----google/
　　`|----android/
　　`|----update-binary
　　`|----updater-script
　　`|----android/
　　`|----metadata
　　二、 update.zip包目录结构详解
　　以上是我们用命令make otapackage 制作的update.zip包的标准目录结构。
　　1、boot.img是更新boot分区所需要的文件。这个boot.img主要包括kernel+ramdisk。
　　2、system/目录的内容在升级后会放在系统的system分区。主要用来更新系统的一些应用或则应用会用到的一些库等等。可以将Android源码编译out/target/product/tcc8800/system/中的所有文件拷贝到这个目录来代替。
　　3、recovery/目录中的recovery-from-boot.p是boot.img和recovery.img的补丁(patch),主要用来更新recovery分区，其中etc/目录下的install-recovery.sh是更新脚本。
　　4、update-binary是一个二进制文件，相当于一个脚本解释器，能够识别updater-script中描述的操作。该文件在Android源码编译后out/target/product/tcc8800/system bin/updater生成，可将updater重命名为update-binary得到。
　　该文件在具体的更新包中的名字由源码中bootable/recovery/install.c中的宏ASSUMED_UPDATE_BINARY_NAME的值而定。
　　5、updater-script：此文件是一个脚本文件，具体描述了更新过程。我们可以根据具体情况编写该脚本来适应我们的具体需求。该文件的命名由源码中bootable/recovery/updater/updater.c文件中的宏SCRIPT_NAME的值而定。
　　6、 metadata文件是描述设备信息及环境变量的元数据。主要包括一些编译选项，签名公钥，时间戳以及设备型号等。
　　7、我们还可以在包中添加userdata目录，来更新系统中的用户数据部分。这部分内容在更新后会存放在系统的/data目录下。
　　8、update.zip包的签名：update.zip更新包在制作完成后需要对其签名，否则在升级时会出现认证失败的错误提示。而且签名要使用和目标板一致的加密公钥。加密公钥及加密需要的三个文件在Android源码编译后生成的具体路径为：
　　out/host/linux-x86/framework/signapk.jar
　　build/target/product/security/testkey.x509.pem
　　build/target/product/security/testkey.pk8 。
　　我们用命令make otapackage制作生成的update.zip包是已签过名的，如果自己做update.zip包时必须手动对其签名。
　　具体的加密方法：$ java –jar gingerbread/out/host/linux/framework/signapk.jar –w gingerbread/build/target/product/security/testkey.x509.pem gingerbread/build/target/product/security/testkey.pk8 update.zip update_signed.zip
　　以上命令在update.zip包所在的路径下执行，其中signapk.jar testkey.x509.pem以及testkey.pk8文件的引用使用绝对路径。update.zip 是我们已经打好的包，update_signed.zip包是命令执行完生成的已经签过名的包。
　　9、MANIFEST.MF：这个manifest文件定义了与包的组成结构相关的数据。类似Android应用的mainfest.xml文件。
　　10、CERT.RSA：与签名文件相关联的签名程序块文件，它存储了用于签名JAR文件的公共签名。
　　11、CERT.SF：这是JAR文件的签名文件，其中前缀CERT代表签名者。
　　另外，在具体升级时，对update.zip包检查时大致会分三步：①检验SF文件与RSA文件是否匹配。②检验MANIFEST.MF与签名文件中的digest是否一致。③检验包中的文件与MANIFEST中所描述的是否一致。
　　三、 Android升级包update.zip的生成过程分析
　　1) 对于update.zip包的制作有两种方式，即手动制作和命令生成。
　　第一种手动制作：即按照update.zip的目录结构手动创建我们需要的目录。然后将对应的文件拷贝到相应的目录下，比如我们向系统中新加一个应用程序。可以将新增的应用拷贝到我们新建的update/system/app/下（system目录是事先拷贝编译源码后生成的system目录），打包并签名后，拷贝到SD卡就可以使用了。这种方式在实际的tcc8800开发板中未测试成功。签名部分未通过，可能与具体的开发板相关。
　　第二种制作方式：命令制作。Android源码系统中为我们提供了制作update.zip刷机包的命令，即make otapackage。该命令在编译源码完成后并在源码根目录下执行。 具体操作方式：在源码根目录下执行
　　①$ . build/envsetup.sh。
　　②$ lunch 然后选择你需要的配置(如17)。
　　③$ make otapackage。
　　在编译完源码后最好再执行一遍上面的①、②步防止执行③时出现未找到对应规则的错误提示。命令执行完成后生成的升级包所在位置在out/target/product/full_tcc8800_evm_target_files-eng.mumu.20120309.111059.zip将这个包重新命名为update.zip，并拷贝到SD卡中即可使用。
　　这种方式(即完全升级)在tcc8800开发板中已测试成功。
　　2) 使用make otapackage命令生成update.zip的过程分析。
　　在源码根目录下执行make otapackage命令生成update.zip包主要分为两步，第一步是根据Makefile执行编译生成一个update原包（zip格式）。第二步是运行一个python脚本，并以上一步准备的zip包作为输入，最终生成我们需要的升级包。下面进一步分析这两个过程。
　　第一步：编译Makefile。对应的Makefile文件所在位置：build/core/Makefile。从该文件的884行（tcc8800,gingerbread0919）开始会生成一个zip包，这个包最后会用来制作OTA package 或者filesystem image。先将这部分的对应的Makefile贴出来如下：

　　[python] view plaincopyprint?
　　# -----------------------------------------------------------------
　　# A zip of the directories that map to the target filesystem.
　　# This zip can be used to create an OTA package or filesystem image
　　# as a post-build step.
　　#
　　根据上面的Makefile可以分析这个包的生成过程：
　　首先创建一个root_zip根目录，并依次在此目录下创建所需要的如下其他目录
　　①创建RECOVERY目录，并填充该目录的内容，包括kernel的镜像和recovery根文件系统的镜像。此目录最终用于生成recovery.img。
　　②创建并填充BOOT目录。包含kernel和cmdline以及pagesize大小等，该目录最终用来生成boot.img。
　　③向SYSTEM目录填充system image。
　　④向DATA填充data image。
　　⑤用于生成OTA package包所需要的额外的内容。主要包括一些bin命令。
　　⑥创建META目录并向该目录下添加一些文本文件，如apkcerts.txt(描述apk文件用到的认证证书)，misc_info.txt(描述Flash内存的块大小以及boot、recovery、system、userdata等分区的大小信息)。
　　⑦使用保留连接选项压缩我们在上面获得的root_zip目录。
　　⑧使用fs_config(build/tools/fs_config)配置上面的zip包内所有的系统文件(system/下各目录、文件)的权限属主等信息。fs_config包含了一个头文件#include“private/android_filesystem_config.h”。在这个头文件中以硬编码的方式设定了system目录下各文件的权限、属主。执行完配置后会将配置后的信息以文本方式输出 到META/filesystem_config.txt中。并再一次zip压缩成我们最终需要的原始包。
　　第二步：上面的zip包只是一个编译过程中生成的原始包。这个原始zip包在实际的编译过程中有两个作用，一是用来生成OTA update升级包，二是用来生成系统镜像。在编译过程中若生成OTA update升级包时会调用（具体位置在Makefile的1037行到1058行）一个名为ota_from_target_files的python脚本，位置在/build/tools/releasetools/ota_from_target_files。这个脚本的作用是以第一步生成的zip原始包作为输入，最终生成可用的OTA升级zip包。
　　二 下面我们分析ota_from_target_files这个python脚本是怎样生成最终zip包的。先讲这个脚本的代码贴出来如下：
　　[python] view plaincopyprint?
　　import sys
　　if sys.hexversion < 0x02040000:
　　print >> sys.stderr, "Python 2.4 or newer is required."
　　sys.exit(1)
　　主函数main是python的入口函数，我们从main函数开始看，大概看一下main函数（脚本最后）里的流程就能知道脚本的执行过程了。
　　① 在main函数的开头，首先将用户设定的option选项存入OPTIONS变量中，它是一个python中的类。紧接着判断有没有额外的脚本，如果有就读入到OPTIONS变量中。
　　② 解压缩输入的zip包，即我们在上文生成的原始zip包。然后判断是否用到device-specific extensions（设备扩展）如果用到，随即读入到OPTIONS变量中。
　　③ 判断是否签名，然后判断是否有新内容的增量源，有的话就解压该增量源包放入一个临时变量中（source_zip）。自此，所有的准备工作已完毕，随即会调用该 脚本中最主要的函数WriteFullOTAPackage(input_zip,output_zip)
　　④ WriteFullOTAPackage函数的处理过程是先获得脚本的生成器。默认格式是edify。然后获得metadata元数据，此数据来至于Android的一些环境变量。然后获得设备配置参数比如api函数的版本。然后判断是否忽略时间戳。
　　⑤ WriteFullOTAPackage函数做完准备工作后就开始生成升级用的脚本文件(updater-script)了。生成脚本文件后将上一步获得的metadata元数据写入到输出包out_zip。
　　⑥至此一个完整的update.zip升级包就生成了。生成位置在：out/target/product/tcc8800/full_tcc8800_evm-ota-eng.mumu.20120315.155326.zip。将升级包拷贝到SD卡中就可以用来升级了。
　　四、 Android OTA增量包update.zip的生成
　　在上面的过程中生成的update.zip升级包是全部系统的升级包。大小有80M多。这对手机用户来说，用来升级的流量是很大的。而且在实际升级中，我们只希望能够升级我们改变的那部分内容。这就需要使用增量包来升级。生成增量包的过程也需要上文中提到的ota_from_target_files.py的参与。
　　下面是制作update.zip增量包的过程。
　　① 在源码根目录下依次执行下列命令
　　$ . build/envsetup.sh
　　$ lunch 选择17
　　$ make
　　$ make otapackage
　　执行上面的命令后会在out/target/product/tcc8800/下生成我们第一个系统升级包。我们先将其命名为A.zip
　　② 在源码中修改我们需要改变的部分，比如修改内核配置，增加新的驱动等等。修改后再一次执行上面的命令。就会生成第二个我们修改后生成的update.zip升级包。将 其命名为B.zip。
　　③ 在上文中我们看了ota_from_target_files.py脚本的使用帮助，其中选项-i就是用来生成差分增量包的。使用方法是以上面的A.zip 和B.zip包作为输入，以update.zip包作 为输出。生成的update.zip就是我们最后需要的增量包。
　　具体使用方式是：将上述两个包拷贝到源码根目录下，然后执行下面的命令。
　　$ ./build/tools/releasetools/ota_from_target_files -i A.zip B.zip update.zip。
　　在执行上述命令时会出现未找到recovery_api_version的错误。原因是在执行上面的脚本时如果使用选项i则会调用WriteIncrementalOTAPackage会从A包和B包中的META目录下搜索misc_info.txt来读取recovery_api_version的值。但是在执行make otapackage命令时生成的update.zip包中没有这个目录更没有这个文档。
　　此时我们就需要使用执行make otapackage生成的原始的zip包。这个包的位置在out/target/product/tcc8800/obj/PACKAGING/target_files_intermediates/目录下，它是在用命令make otapackage之后的中间生产物，是最原始的升级包。我们将两次编译的生成的包分别重命名为A.zip和B.zip，并拷贝到SD卡根目录下重复执行上面的命令：
　　$ ./build/tools/releasetools/ota_form_target_files -i A.zip B.zip update.zip。
　　在上述命令即将执行完毕时，在device/telechips/common/releasetools.py会调用IncrementalOTA_InstallEnd,在这个函数中读取包中的RADIO/bootloader.img。
　　而包中是没有这个目录和bootloader.img的。所以执行失败，未能生成对应的update.zip。可能与我们未修改bootloader（升级firmware）有关。此问题在下一篇博客已经解决。
制作增量包失败的原因，以及解决方案。

　　Android系统Recovery工作原理之使用update.zip升级过程分析（二）---update.zip差分包问题的解决
　　在上一篇末尾提到的生成差分包时出现的问题，现已解决，由于最近比较忙，相隔的时间也比较长，所以单列一个篇幅提示大家。这个问题居然是源码中的问题，可能你已经制作成功了，不过我的这个问题确实是源码中的一个问题，不知道是不是一个bug，下文会具体分析！
　　一、生成OTA增量包失败的解决方案
　　在上一篇中末尾使用ota_from_target_files脚本制作update.zip增量包时失败，我们先将出现的错误贴出来。
　　在执行这个脚本的最后读取input_zip中RADIO/bootloader.img时出现错误，显示DeviceSpecifiParams这个对象中没有input_zip属性。
　　我们先从脚本中出现错误的调用函数中开始查找。出现错误的调用地方是在函WriteIncrementalOTAPackage（443行）中的device_specific.IncrementalOTA_InstallEnd()，其位于WriteIncrementalOTAPackage()中的末尾。进一步跟踪源码发现，这是一个回调函数，他的具体执行方法位于源码中/device/telechips/common/releasetools.py脚本中的IncrementalOTA_InstallEnd()函数。下面就分析这个函数的作用。
　　releasetools.py脚本中的两个函数FullOTA_InstallEnd()和IncrementalOTA_InstallEnd()的作用都是从输入包中读取RADIO/下的bootloader.img文件写到输出包中，同时生成安装bootloader.img时执行脚本的那部分命令。只不过一个是直接将输入包中的bootloader.img镜像写到输出包中，一个是先比较target_zip和source_zip中的bootloader.img是否不同（使用选项-i生成差分包时），然后将新的镜像写入输出包中。下面先将这个函数(位于/device/telechips/common/releasetools.py)的具体实现贴出来：
　　我们的实际情况是，在用命令make otapackage时生成的包中是没有这个RADIO目录下的bootloader.img镜像文件（因为这部分更新已被屏蔽掉了）。但是这个函数中对于从包中未读取到bootloader.img文件的情况是有错误处理的，即返回。所以我们要从 出现的实际错误中寻找问题的原由。
　　真正出现错误的地方是：
　　target_bootloader=info.input_zip.read(“RADIO/bootloader.img”)。
　　出现错误的原因是：AttributeError：‘DeviceSpecificParams’object has no attribute ‘input_zip’，提示我们DeviceSpecificParams对象没有input_zip这个属性。
　　二、updater-script脚本执行流程分析：
　　先看一下在测试过程中用命令make otapackage生成的升级脚本如下：
　　[python] view plaincopyprint?
　　assert(!less_than_int(1331176658, getprop("ro.build.date.utc")));
　　assert(getprop("ro.product.device") == "tcc8800" ||
　　下面分析下这个脚本的执行过程：
　　①比较时间戳：如果升级包较旧则终止脚本的执行。
　　②匹配设备信息：如果和当前的设备信息不一致，则停止脚本的执行。
　　③显示进度条：如果以上两步匹配则开始显示升级进度条。
　　④格式化system分区并挂载。
　　⑤提取包中的recovery以及system目录下的内容到系统的/system下。
　　⑥为/system/bin/下的命令文件建立符号连接。
　　⑦设置/system/下目录以及文件的属性。
　　⑧将包中的boot.img提取到/tmp/boot.img。
　　⑨将/tmp/boot.img镜像文件写入到boot分区。
　　⑩完成后卸载/system。
　　三、总结
　　以上的九篇着重分析了Android系统中Recovery模式中的一种，即我们做好的update.zip包在系统更新时所走过的流程。其核心部分就是Recovery服务的工作原理。其他两种FACTORY RESET、ENCRYPTED FILE SYSTEM ENABLE/DISABLE与OTA INSTALL是相通的。重点是要理解Recovery服务的工作原理。另外详细分析其升级过程，对于我们在实际升级时，可以根据我们的需要做出相应的修改。 参考技术A 包可以用RE管理器提取System。下个签名工具就可以了，一般好像要刷入第三方中文REC才可以刷机。追问

就是想问有什么签名工具

追答

直接百度rom签名工具，一堆

本回答被提问者采纳 参考技术B XT702刷机教程之使用OpenRecovery刷zip格式升级包。 1、下载好OpenRecovery，可以... 执行一下Reboot System重启手机，第一次重启可能会进入recovery界面，再次选择...