- 浏览: 81306 次
- 性别:
- 来自: 西安
文章分类
最新评论
-
_lsliang:
直接使用Query的addEntity方法?
获取多表中的数据 -
zhangkehbg:
待续~~~~
几种常用的排序算法
Recovery 模式最主要的两个功能是恢复出厂设置和升级系统版本。本Recovery相关的分析内容主要为两部分:FACTORY RESET+OTA INSTALL
Recovery模式的主界面
进入recovery的方式
我公司手机一般正确手动进入recovery模式的方式为:power+volume up+volume down
手机开机后,硬件系统上电,完成一系列的初始化工作:CPU、串口、终端、timer、DDR等硬件设备,然后加载bootloader,为后面内核加载做准备工作。在系统启动初始化完成后系统检测进入哪一种工作模式,这一部分代码的源文件在\bootable\bootloader\lk\app\aboot\aboot.c文件的aboot_init()函数中:
检测用户关机方式,如果是强制关机,则进入normal_boot模式
if (is_user_force_reset())
goto normal_boot;
检测音量上下键的按键状态,判断进入何种模式:
if (keys_get_state(KEY_VOLUMEUP) && keys_get_state(KEY_VOLUMEDOWN))
{
dprintf(ALWAYS,"dload mode key sequence detected\n");
if (set_download_mode(EMERGENCY_DLOAD))
{
dprintf(CRITICAL,"dload mode not supported by target\n");
}
else
{
reboot_device(DLOAD);
dprintf(CRITICAL,"Failed to reboot into dload mode\n");
}
boot_into_fastboot = true;
}
if (!boot_into_fastboot)
{
if (keys_get_state(KEY_HOME) || keys_get_state(KEY_VOLUMEUP))
boot_into_recovery = 1;
if (!boot_into_recovery &&
(keys_get_state(KEY_BACK) || keys_get_state(KEY_VOLUMEDOWN)))
boot_into_fastboot = true;
}
根据以上代码,开机过程中按home键或者音量上键会进入recovery模式,按back键或者音量下键会进入fastboot模式。
如果没有组合键(代码中称为magic key)按下,则会检测SMEM(在后头会介绍SMEM的的来源) 中的reboot_mode 变量值。
reboot_mode = check_reboot_mode();
hard_reboot_mode = check_hard_reboot_mode();
if (reboot_mode == RECOVERY_MODE ||
hard_reboot_mode == RECOVERY_HARD_RESET_MODE) {
boot_into_recovery = 1;
} else if(reboot_mode == FASTBOOT_MODE ||
hard_reboot_mode == FASTBOOT_HARD_RESET_MODE) {
boot_into_fastboot = true;
} else if(reboot_mode == ALARM_BOOT ||
hard_reboot_mode == RTC_HARD_RESET_MODE) {
boot_reason_alarm = true;
}
reboot_mode 可取的值宏定义为:
#define FASTBOOT_MODE 0x77665500
#define RECOVERY_MODE 0x77665502
而check_reboot_mode 函数定义在\bootable\bootloader\lk\target\ msm8916\init.c 中,函数先读取restart_reason_addr 处的数值,定义为0x2A05F65C,没有采取宏定义,属于不规范的表达。读取完该值之后,在该地址写入0x00,即擦除其内容,以防下次启动又进入recovery 模式。
unsigned check_reboot_mode(void)
{
uint32_t restart_reason = 0;
/* Read reboot reason and scrub it */
restart_reason = readl(RESTART_REASON_ADDR);
writel(0x00, RESTART_REASON_ADDR);
return restart_reason;
}
如果reboot_mode 的值没有定义,则读取MISC 分区的BCB 进行判断,调用函数为recovery_init(),其实现在\bootable\bootloader\lk\app\aboot\recovery.c 中,函数先通过调用get_recovery_message()把BCB 读到recovery_message 结构体中,再读取其command 字段。如果字段是“boot-recovery”,则进入recovery 模式;如果是“update-radio”,则进入固件升级流程。
系统启动流程分析图
如果以上条件皆不满足,则进入正常启动序列,系统会加载boot.img文件,然后加载kernel,在内核加载完成之后,会根据内核的传递参数寻找android的第一个用户进程,即init进程,该进程根据init.rc以及init.$(hardware).rc脚本文件来启动android的必要的服务,直到完成android系统的启动。
当进入recovery模式时,系统加载的是recovery.img文件,该文件内容与boot.img类似,也包含了标准的内核和根文件系统。但是recovery.img为了具有恢复系统的能力,比普通的boot.img目录结构中:
1、多了/res/images目录,在这个目录下的图片是恢复时我们看到的背景画面。
2、多了/sbin/recovery二进制程序,这个就是恢复用的程序。
3、/sbin/adbd不一样,recovery模式下的adbd不支持shell。
4、初始化程序(init)和初始化配置文件(init.rc)都不一样。这就是系统没有进入图形界面而进入了类似文本界面,并可以通过简单的组合键进行恢复的原因。
与正常启动系统类似,也是启动内核,然后启动文件系统。在进入文件系统后会执行/init,init的配置文件就是 /init.rc。这个配置文件位于bootable/recovery/etc/init.rc。查看这个文件我们可以看到它做的事情很简单:
1) 设置环境变量。
2) 建立etc连接。
3) 新建目录,备用。
4) 挂载文件系统。
5) 启动recovery(/sbin/recovery)服务。
6) 启动adbd服务(用于调试)。
上文所提到的fastboot模式,即命令或SD卡烧写模式,不加载内核及文件系统,此处可以进行工厂模式的烧写。
综上所述,有三种进入recovery模式的方法,分别是开机时按组合键,写SMEM中的reboot_mode变量值,以及写位于MISC分区的BCB中的command字段。
通过命令进入recovery模式:adb reboot recovery
Recovery主界面内容分析
OTA工作过程
升级所需要的update.zip包来源有两种,一是OTA在线下载(一般下载到/CACHE分区),二是手动拷贝到SD卡中。不论是哪种方式获得update.zip包,在进入Recovery模式前,都未对这个zip包做处理。只是在重启之前将zip包的路径告诉了Recovery服务。
当选择升级后,调用RecoverySystem类的installPackage()方法。这个函数首先根据传过来的包文件,获取这个包文件的绝对路径filename,然后将其拼成arg = “--update_package=” + filename,最终会被写入到BCB中,这个就是重启进入Recovery模式后,Recovery服务要进行的操作。它被传递到函数bootCommand(context,arg),在这个函数中才是Main System在重启前真正做的准备。
Recovery模式主要的执行过程在bootable/recovery/recovery.cpp中,这里从main()函数开始分析
Int main(int argc,char **argv){
…… ……
}
具体执行流程如下:
1、在函数的开始会对argc和argv进行检验:
if (argc == 2 && strcmp(argv[1], "--adbd") == 0) {
adb_main();//进入adb_main()过程
return 0;
}
2、 Load and parse volume data from /etc/recovery.fstab.
void load_volume_table();该函数在bootable/recovery/roots.cpp中,主要功能根据“etc/recovery.fstab”加载和解析分区;
3、确保参数传入的分区是被成功mounted,成功时返回0
ensure_path_mounted(LAST_LOG_FILE);// LAST_LOG_FILE =”/cache/recovery/last_log”存放的是最近一次的recovery过程的日志文件;
4、重命名日志, Rename last_log -> last_log.1 -> last_log.2 -> ... -> last_log.$max
rotate_last_logs(KEEP_LOG_COUNT);// KEEP_LOG_COUNT不超过10个
5、获取命令参数,get_args(&argc, &argv);
如果参数未提供,则从BCB(Bootloader Control Block)查找,如果BCB中也没有则尝试在命令文件中查找相应的命令,将最终获得的参数写进BCB中,直到finish_recovery被调用完,再从BCB中清除。
6、根据命令参数给控制变量赋值,具体过程见如下的循环:
while ((arg = getopt_long(argc, argv, "", OPTIONS, NULL)) != -1) {
switch (arg) {
case 's': send_intent = optarg; break;
case 'u': update_package = optarg; break;
case 'w': wipe_data = wipe_cache = 1; break;
case 'c': wipe_cache = 1; break;
case 't': show_text = 1; break;
case 'x': just_exit = true; break;
case 'l': locale = optarg; break;
case 'g': {
if (stage == NULL || *stage == '\0') {
char buffer[20] = "1/";
strncat(buffer, optarg, sizeof(buffer)-3);
stage = strdup(buffer);
}
break;
}
case 'p': shutdown_after = true; break;
case 'r': reason = optarg; break;
case '?':
LOGE("Invalid command argument\n");
continue;
}
}
其中的OPTIONS定义如下:
static const struct option OPTIONS[] = {
{ "send_intent", required_argument, NULL, 's' },
{ "update_package", required_argument, NULL, 'u' },
{ "wipe_data", no_argument, NULL, 'w' },
{ "wipe_cache", no_argument, NULL, 'c' },
{ "show_text", no_argument, NULL, 't' },
{ "just_exit", no_argument, NULL, 'x' },
{ "locale", required_argument, NULL, 'l' },
{ "stages", required_argument, NULL, 'g' },
{ "shutdown_after", no_argument, NULL, 'p' },
{ "reason", required_argument, NULL, 'r' },
{ NULL, 0, NULL, 0 },
};
此处这样做的原因我认为是Java中swich case中智能使用单个字符,例如’c’,’x’等,通过转换获得其参数命令后给对应的控制变量赋值。
从以上的参数可以判断locale值,从cache中加载现场
if (locale == NULL) {
load_locale_from_cache();
//从cache/recovery/last_locale文件中获得
}
7、初始化UI界面:Recovery 服务使用了一个基于framebuffer 的miniui 系统,ui_init 函数对其进行了简单的初始化。在Recovery 服务的过程中主要用于显示一个背景图片(正在安装或安装失败)和一个进度条(用于显示进度)。另外还启动了两个线程,一个用于处理进度条的显示(progress_thread),另一个用于响应用户的按键(input_thread)。
获得recovery过程使用的device :Device* device = make_device();
进一步获得Recovery_Ui对象:ui=device->GetUI();并对ui进行初始化和现场设置。
在Init()之后调用SetStage(),显示一个状态指示
设置背景SetBackground(RecoveryUI::NONE);
调用显示内容,ShowText(true),内部调用update_screen_locked(),用来重新绘制更新界面。
到这为止做的准备工作基本完成:参数已经被解析、初始化完成、UI被捕获以及绘制,接着进行的recovery核心部分,调用StartRecovery()。
8、执行recovery操作
if (update_package != NULL) {
status = install_package(update_package, &wipe_cache, TEMPORARY_INSTALL_FILE, true);
if (status == INSTALL_SUCCESS && wipe_cache) {
if (erase_volume("/cache")) {
LOGE("Cache wipe (requested by package) failed.");
}
}
if (status != INSTALL_SUCCESS) {
ui->Print("Installation aborted.\n");
// If this is an eng or userdebug build, then automatically
// turn the text display on if the script fails so the error
// message is visible.
char buffer[PROPERTY_VALUE_MAX+1];
property_get("ro.build.fingerprint", buffer, "");
if (strstr(buffer, ":userdebug/") || strstr(buffer, ":eng/")) {
ui->ShowText(true);
}
}
} else if (wipe_data) {
if (device->WipeData()) status = INSTALL_ERROR;
if (erase_volume("/data")) status = INSTALL_ERROR;
if (wipe_cache && erase_volume("/cache")) status = INSTALL_ERROR;
if (status != INSTALL_SUCCESS) ui->Print("Data wipe failed.\n");
} else if (wipe_cache) {
if (wipe_cache && erase_volume("/cache")) status = INSTALL_ERROR;
if (status != INSTALL_SUCCESS) ui->Print("Cache wipe failed.\n");
} else if (!just_exit) {
status = INSTALL_NONE; // No command specified
ui->SetBackground(RecoveryUI::NO_COMMAND);
}
判断update_package是否存在,若存在则调用install_package()进行升级包更新,在此过程如果返回INSTALL_SUCCESS且wipe_cache is true,则执行wipe cache partition;
install_package(update_package, &wipe_cache, TEMPORARY_INSTALL_FILE, true)
如果update_package为NULL,wipe_data为true则进行device->WipeData()、erase_volume(“/data”)、erase_volume(“/cache”)操作;
如果wipe_cache为true,则执行erase_volume(“/cache”);
9、根据6过程中中shutdown_after的赋值以及8过程中返回的更新结果返回的状态status更新后续操作:
Device::BuiltinAction after = shutdown_after ? Device::SHUTDOWN : Device::REBOOT;
if (status != INSTALL_SUCCESS || ui->IsTextVisible()) {
ui->ShowText(true);
Device::BuiltinAction temp = prompt_and_wait(device, status);
if (temp != Device::NO_ACTION) after = temp;
}
10、执行recovery后续工作:清除recovery相关的命令,准备启动系统,并copy日志文件到cache、记录intent跟main system沟通、删除命令文件、卸载cache分区。
finish_recovery(send_intent);
(1) 将intent(字符串)的内容作为参数传进finish_recovery 中。如果有intent 需要告知Main System,则将其写入/cache/recovery/intent 中。
(2) 将内存文件系统中的Recovery 服务的日志(/tmp/recovery.log)拷贝到cache 分区中的 /cache/recovery/log 文件,以便告知重启后的Main System 发生过什么。
(3) 擦除MISC 分区中的BCB 数据块的内容,以便系统重启后不再进入Recovery 模式,而是进入更新后的主系统。
(4) 删除/cache/recovery/command 文件。这一步也是很重要的,因为重启后bootloader 会自动检索这个文件,如果未删除的话又会进入Recovery 模式。
11、根据在9步设置的after的值对手机的后续操作进行设定
switch (after) {
case Device::SHUTDOWN:
ui->Print("Shutting down...\n");
property_set(ANDROID_RB_PROPERTY, "shutdown,");
break;
case Device::REBOOT_BOOTLOADER:
ui->Print("Rebooting to bootloader...\n");
property_set(ANDROID_RB_PROPERTY, "reboot,bootloader");
break;
default:
ui->Print("Rebooting...\n");
property_set(ANDROID_RB_PROPERTY, "reboot,");
break;
}
最后手机进行关机或者重启或者reboot bootloader模式
从上层进入recovery服务
在setting-->备份与重置--->恢复出厂设置--->重置手机--->手机关机--->开机--->进行恢复出厂的操作--->开机流程。
恢复出厂设置其实是擦除用户数据分区,同时删除缓存区。在系统设置中选择“恢复出厂设置”选项后, APK 会发出一个广播:“android.intent.action.MASTER_CLEAR”,接收者是MasterClearReceiver 类,在收到广播之后会开启一个新线程:
public void onReceive(final Context context, final Intent intent) {
……
// The reboot call is blocking, so we need to do it on another thread.
Thread thr = new Thread("Reboot") {
@Override
public void run() {
try {
RecoverySystem.rebootWipeUserData(context, shutdown, reason);
Log.wtf(TAG, "Still running after master clear?!");
} catch (IOException e) {
Slog.e(TAG, "Can't perform master clear/factory reset", e);
} catch (SecurityException e) {
Slog.e(TAG, "Can't perform master clear/factory reset", e);
}
}
};
thr.start();
}
线程中调用了\frameworks\base\core\java\android\os\RecoverySystem.java类的rebootWipeUserData方法:
public static void rebootWipeUserData(Context context, boolean shutdown, String reason) throws IOException {
UserManager um = (UserManager) context.getSystemService(Context.USER_SERVICE);
if (um.hasUserRestriction(UserManager.DISALLOW_FACTORY_RESET)) {
throw new SecurityException("Wiping data is not allowed for this user.");
}
final ConditionVariable condition = new ConditionVariable();
Intent intent = new Intent("android.intent.action.MASTER_CLEAR_NOTIFICATION");
intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);
context.sendOrderedBroadcastAsUser(intent, UserHandle.OWNER,
android.Manifest.permission.MASTER_CLEAR,
new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
condition.open();
}
}, null, 0, null, null);
// Block until the ordered broadcast has completed.
condition.block();
String shutdownArg = null;
if (shutdown) {
shutdownArg = "--shutdown_after";
}
String reasonArg = null;
if (!TextUtils.isEmpty(reason)) {
reasonArg = "--reason=" + sanitizeArg(reason);
}
final String localeArg = "--locale=" + Locale.getDefault().toString();
bootCommand(context, shutdownArg, "--wipe_data", reasonArg, localeArg);
}
最终调用bootCommand(context, shutdownArg, "--wipe_data", reasonArg, localeArg);完成擦除数据的操作
bootCommand()函数分析:
/**重启进入recovery系统同时传入提供的参数*/
private static void bootCommand(Context context, String... args) throws IOException {
RECOVERY_DIR.mkdirs(); // In case we need it
COMMAND_FILE.delete(); // In case it's not writable
LOG_FILE.delete();
FileWriter command = new FileWriter(COMMAND_FILE);
//将参数逐行写入command文件中
try {
for (String arg : args) {
if (!TextUtils.isEmpty(arg)) {
command.write(arg);
command.write("\n");
}
}
} finally {
command.close();
}
// 写入cache/recovery/command文件中后,继续执行reboot的后续操作
PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
//这里执行reboot操作进入recovery模式
pm.reboot(PowerManager.REBOOT_RECOVERY);
throw new IOException("Reboot failed (no permissions?)");
}
这里进入recovery模式的入口在于: frameworks\base\core\java\android\os\PowerManager.java
public void reboot(String reason) {
try {
mService.reboot(false, reason, true);
} catch (RemoteException e) {
}
}
IPowerManager.aidl文件中的方法如下:
void reboot(boolean confirm, String reason, boolean wait);
其中对应的实现位于PowerManagerService.java中的内部类BinderService中:
private final class BinderService extends IPowerManager.Stub {
……
@Override // Binder call
public void reboot(boolean confirm, String reason, boolean wait) {
mContext.enforceCallingOrSelfPermission(android.Manifest.permission.REBOOT, null);
if (PowerManager.REBOOT_RECOVERY.equals(reason)) {
mContext.enforceCallingOrSelfPermission(android.Manifest.permission.RECOVERY, null);
}
final long ident = Binder.clearCallingIdentity();
try {
shutdownOrRebootInternal(false, confirm, reason, wait);
} finally {
Binder.restoreCallingIdentity(ident);
}
}
……
}
bootCommand()经过如下调用后最终到调用到本地JNI 接口rebootNative(),就是\frameworks\base\core\jni\android_os_Power.cpp 中的android_os_Power_reboot 函数。
具体的调用流程如下:
该函数继续调用\system\core\libcutils\android_reboot.c 中的int android_reboot(int cmd, int flags UNUSED, char *arg),该函数根据第一个参数的不同走向不同的分支,
switch (cmd) {
case ANDROID_RB_RESTART:
ret = reboot(RB_AUTOBOOT);
break;
case ANDROID_RB_POWEROFF:
ret = reboot(RB_POWER_OFF);
break;
case ANDROID_RB_RESTART2:
ret = syscall(__NR_reboot,LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART2, arg);
break;
default:
ret = -1;
}
相关宏定义见\kernel\include\linux\reboot.h。在reboot.h中定义的函数实现在kernel/kernel/sys.c中的函数 SYSCALL_DEFINE4():为了避免误操作而进入 recovery模式,该函数首先检测所谓的魔法参数,之后判断启动命令,如果是 LINUX_REBOOT_CMD_RESTART2,表示用所给的命令字符串重启系统。调用关系如下:
可以看出,虽然经过了层层调用,但始终有一个内容为“recovery”的字符串参数没有被丢弃过,最后传给了arch_reset(mode, cmd),最终在这里使用:
可以看到,当参数为“recovery”时,会给restart_reason 地址处写入0x77665502。
在代码里有:
45: #define RESTART_REASON_ADDR 0x65C
247: restart_reason = MSM_IMEM_BASE + RESTART_REASON_ADDR;
在\kernel\arch\arm\mach-msm\include\mach\msm_iomap-8x60.h 中有
所以restart_reason 的实际物理地址是0x2A05F000+0x65C =0x2A05F65C,在之前讲到手机启动时, check_reboot_mode 函数会检测SMEM 中的reboot_mode 变量值以判断进入何种工作方式,该函数中读取内存地址0x2A05F65C,这正是arch_reset 函数写入restart_reason 的地址。这样调用pm.reboot(“recovery”) 函数后,最终实现了重启后进入recovery 模式。
Recovery模式的主界面
进入recovery的方式
我公司手机一般正确手动进入recovery模式的方式为:power+volume up+volume down
手机开机后,硬件系统上电,完成一系列的初始化工作:CPU、串口、终端、timer、DDR等硬件设备,然后加载bootloader,为后面内核加载做准备工作。在系统启动初始化完成后系统检测进入哪一种工作模式,这一部分代码的源文件在\bootable\bootloader\lk\app\aboot\aboot.c文件的aboot_init()函数中:
检测用户关机方式,如果是强制关机,则进入normal_boot模式
if (is_user_force_reset())
goto normal_boot;
检测音量上下键的按键状态,判断进入何种模式:
if (keys_get_state(KEY_VOLUMEUP) && keys_get_state(KEY_VOLUMEDOWN))
{
dprintf(ALWAYS,"dload mode key sequence detected\n");
if (set_download_mode(EMERGENCY_DLOAD))
{
dprintf(CRITICAL,"dload mode not supported by target\n");
}
else
{
reboot_device(DLOAD);
dprintf(CRITICAL,"Failed to reboot into dload mode\n");
}
boot_into_fastboot = true;
}
if (!boot_into_fastboot)
{
if (keys_get_state(KEY_HOME) || keys_get_state(KEY_VOLUMEUP))
boot_into_recovery = 1;
if (!boot_into_recovery &&
(keys_get_state(KEY_BACK) || keys_get_state(KEY_VOLUMEDOWN)))
boot_into_fastboot = true;
}
根据以上代码,开机过程中按home键或者音量上键会进入recovery模式,按back键或者音量下键会进入fastboot模式。
如果没有组合键(代码中称为magic key)按下,则会检测SMEM(在后头会介绍SMEM的的来源) 中的reboot_mode 变量值。
reboot_mode = check_reboot_mode();
hard_reboot_mode = check_hard_reboot_mode();
if (reboot_mode == RECOVERY_MODE ||
hard_reboot_mode == RECOVERY_HARD_RESET_MODE) {
boot_into_recovery = 1;
} else if(reboot_mode == FASTBOOT_MODE ||
hard_reboot_mode == FASTBOOT_HARD_RESET_MODE) {
boot_into_fastboot = true;
} else if(reboot_mode == ALARM_BOOT ||
hard_reboot_mode == RTC_HARD_RESET_MODE) {
boot_reason_alarm = true;
}
reboot_mode 可取的值宏定义为:
#define FASTBOOT_MODE 0x77665500
#define RECOVERY_MODE 0x77665502
而check_reboot_mode 函数定义在\bootable\bootloader\lk\target\ msm8916\init.c 中,函数先读取restart_reason_addr 处的数值,定义为0x2A05F65C,没有采取宏定义,属于不规范的表达。读取完该值之后,在该地址写入0x00,即擦除其内容,以防下次启动又进入recovery 模式。
unsigned check_reboot_mode(void)
{
uint32_t restart_reason = 0;
/* Read reboot reason and scrub it */
restart_reason = readl(RESTART_REASON_ADDR);
writel(0x00, RESTART_REASON_ADDR);
return restart_reason;
}
如果reboot_mode 的值没有定义,则读取MISC 分区的BCB 进行判断,调用函数为recovery_init(),其实现在\bootable\bootloader\lk\app\aboot\recovery.c 中,函数先通过调用get_recovery_message()把BCB 读到recovery_message 结构体中,再读取其command 字段。如果字段是“boot-recovery”,则进入recovery 模式;如果是“update-radio”,则进入固件升级流程。
系统启动流程分析图
如果以上条件皆不满足,则进入正常启动序列,系统会加载boot.img文件,然后加载kernel,在内核加载完成之后,会根据内核的传递参数寻找android的第一个用户进程,即init进程,该进程根据init.rc以及init.$(hardware).rc脚本文件来启动android的必要的服务,直到完成android系统的启动。
当进入recovery模式时,系统加载的是recovery.img文件,该文件内容与boot.img类似,也包含了标准的内核和根文件系统。但是recovery.img为了具有恢复系统的能力,比普通的boot.img目录结构中:
1、多了/res/images目录,在这个目录下的图片是恢复时我们看到的背景画面。
2、多了/sbin/recovery二进制程序,这个就是恢复用的程序。
3、/sbin/adbd不一样,recovery模式下的adbd不支持shell。
4、初始化程序(init)和初始化配置文件(init.rc)都不一样。这就是系统没有进入图形界面而进入了类似文本界面,并可以通过简单的组合键进行恢复的原因。
与正常启动系统类似,也是启动内核,然后启动文件系统。在进入文件系统后会执行/init,init的配置文件就是 /init.rc。这个配置文件位于bootable/recovery/etc/init.rc。查看这个文件我们可以看到它做的事情很简单:
1) 设置环境变量。
2) 建立etc连接。
3) 新建目录,备用。
4) 挂载文件系统。
5) 启动recovery(/sbin/recovery)服务。
6) 启动adbd服务(用于调试)。
上文所提到的fastboot模式,即命令或SD卡烧写模式,不加载内核及文件系统,此处可以进行工厂模式的烧写。
综上所述,有三种进入recovery模式的方法,分别是开机时按组合键,写SMEM中的reboot_mode变量值,以及写位于MISC分区的BCB中的command字段。
通过命令进入recovery模式:adb reboot recovery
Recovery主界面内容分析
OTA工作过程
升级所需要的update.zip包来源有两种,一是OTA在线下载(一般下载到/CACHE分区),二是手动拷贝到SD卡中。不论是哪种方式获得update.zip包,在进入Recovery模式前,都未对这个zip包做处理。只是在重启之前将zip包的路径告诉了Recovery服务。
当选择升级后,调用RecoverySystem类的installPackage()方法。这个函数首先根据传过来的包文件,获取这个包文件的绝对路径filename,然后将其拼成arg = “--update_package=” + filename,最终会被写入到BCB中,这个就是重启进入Recovery模式后,Recovery服务要进行的操作。它被传递到函数bootCommand(context,arg),在这个函数中才是Main System在重启前真正做的准备。
Recovery模式主要的执行过程在bootable/recovery/recovery.cpp中,这里从main()函数开始分析
Int main(int argc,char **argv){
…… ……
}
具体执行流程如下:
1、在函数的开始会对argc和argv进行检验:
if (argc == 2 && strcmp(argv[1], "--adbd") == 0) {
adb_main();//进入adb_main()过程
return 0;
}
2、 Load and parse volume data from /etc/recovery.fstab.
void load_volume_table();该函数在bootable/recovery/roots.cpp中,主要功能根据“etc/recovery.fstab”加载和解析分区;
3、确保参数传入的分区是被成功mounted,成功时返回0
ensure_path_mounted(LAST_LOG_FILE);// LAST_LOG_FILE =”/cache/recovery/last_log”存放的是最近一次的recovery过程的日志文件;
4、重命名日志, Rename last_log -> last_log.1 -> last_log.2 -> ... -> last_log.$max
rotate_last_logs(KEEP_LOG_COUNT);// KEEP_LOG_COUNT不超过10个
5、获取命令参数,get_args(&argc, &argv);
如果参数未提供,则从BCB(Bootloader Control Block)查找,如果BCB中也没有则尝试在命令文件中查找相应的命令,将最终获得的参数写进BCB中,直到finish_recovery被调用完,再从BCB中清除。
6、根据命令参数给控制变量赋值,具体过程见如下的循环:
while ((arg = getopt_long(argc, argv, "", OPTIONS, NULL)) != -1) {
switch (arg) {
case 's': send_intent = optarg; break;
case 'u': update_package = optarg; break;
case 'w': wipe_data = wipe_cache = 1; break;
case 'c': wipe_cache = 1; break;
case 't': show_text = 1; break;
case 'x': just_exit = true; break;
case 'l': locale = optarg; break;
case 'g': {
if (stage == NULL || *stage == '\0') {
char buffer[20] = "1/";
strncat(buffer, optarg, sizeof(buffer)-3);
stage = strdup(buffer);
}
break;
}
case 'p': shutdown_after = true; break;
case 'r': reason = optarg; break;
case '?':
LOGE("Invalid command argument\n");
continue;
}
}
其中的OPTIONS定义如下:
static const struct option OPTIONS[] = {
{ "send_intent", required_argument, NULL, 's' },
{ "update_package", required_argument, NULL, 'u' },
{ "wipe_data", no_argument, NULL, 'w' },
{ "wipe_cache", no_argument, NULL, 'c' },
{ "show_text", no_argument, NULL, 't' },
{ "just_exit", no_argument, NULL, 'x' },
{ "locale", required_argument, NULL, 'l' },
{ "stages", required_argument, NULL, 'g' },
{ "shutdown_after", no_argument, NULL, 'p' },
{ "reason", required_argument, NULL, 'r' },
{ NULL, 0, NULL, 0 },
};
此处这样做的原因我认为是Java中swich case中智能使用单个字符,例如’c’,’x’等,通过转换获得其参数命令后给对应的控制变量赋值。
从以上的参数可以判断locale值,从cache中加载现场
if (locale == NULL) {
load_locale_from_cache();
//从cache/recovery/last_locale文件中获得
}
7、初始化UI界面:Recovery 服务使用了一个基于framebuffer 的miniui 系统,ui_init 函数对其进行了简单的初始化。在Recovery 服务的过程中主要用于显示一个背景图片(正在安装或安装失败)和一个进度条(用于显示进度)。另外还启动了两个线程,一个用于处理进度条的显示(progress_thread),另一个用于响应用户的按键(input_thread)。
获得recovery过程使用的device :Device* device = make_device();
进一步获得Recovery_Ui对象:ui=device->GetUI();并对ui进行初始化和现场设置。
在Init()之后调用SetStage(),显示一个状态指示
设置背景SetBackground(RecoveryUI::NONE);
调用显示内容,ShowText(true),内部调用update_screen_locked(),用来重新绘制更新界面。
到这为止做的准备工作基本完成:参数已经被解析、初始化完成、UI被捕获以及绘制,接着进行的recovery核心部分,调用StartRecovery()。
8、执行recovery操作
if (update_package != NULL) {
status = install_package(update_package, &wipe_cache, TEMPORARY_INSTALL_FILE, true);
if (status == INSTALL_SUCCESS && wipe_cache) {
if (erase_volume("/cache")) {
LOGE("Cache wipe (requested by package) failed.");
}
}
if (status != INSTALL_SUCCESS) {
ui->Print("Installation aborted.\n");
// If this is an eng or userdebug build, then automatically
// turn the text display on if the script fails so the error
// message is visible.
char buffer[PROPERTY_VALUE_MAX+1];
property_get("ro.build.fingerprint", buffer, "");
if (strstr(buffer, ":userdebug/") || strstr(buffer, ":eng/")) {
ui->ShowText(true);
}
}
} else if (wipe_data) {
if (device->WipeData()) status = INSTALL_ERROR;
if (erase_volume("/data")) status = INSTALL_ERROR;
if (wipe_cache && erase_volume("/cache")) status = INSTALL_ERROR;
if (status != INSTALL_SUCCESS) ui->Print("Data wipe failed.\n");
} else if (wipe_cache) {
if (wipe_cache && erase_volume("/cache")) status = INSTALL_ERROR;
if (status != INSTALL_SUCCESS) ui->Print("Cache wipe failed.\n");
} else if (!just_exit) {
status = INSTALL_NONE; // No command specified
ui->SetBackground(RecoveryUI::NO_COMMAND);
}
判断update_package是否存在,若存在则调用install_package()进行升级包更新,在此过程如果返回INSTALL_SUCCESS且wipe_cache is true,则执行wipe cache partition;
install_package(update_package, &wipe_cache, TEMPORARY_INSTALL_FILE, true)
如果update_package为NULL,wipe_data为true则进行device->WipeData()、erase_volume(“/data”)、erase_volume(“/cache”)操作;
如果wipe_cache为true,则执行erase_volume(“/cache”);
9、根据6过程中中shutdown_after的赋值以及8过程中返回的更新结果返回的状态status更新后续操作:
Device::BuiltinAction after = shutdown_after ? Device::SHUTDOWN : Device::REBOOT;
if (status != INSTALL_SUCCESS || ui->IsTextVisible()) {
ui->ShowText(true);
Device::BuiltinAction temp = prompt_and_wait(device, status);
if (temp != Device::NO_ACTION) after = temp;
}
10、执行recovery后续工作:清除recovery相关的命令,准备启动系统,并copy日志文件到cache、记录intent跟main system沟通、删除命令文件、卸载cache分区。
finish_recovery(send_intent);
(1) 将intent(字符串)的内容作为参数传进finish_recovery 中。如果有intent 需要告知Main System,则将其写入/cache/recovery/intent 中。
(2) 将内存文件系统中的Recovery 服务的日志(/tmp/recovery.log)拷贝到cache 分区中的 /cache/recovery/log 文件,以便告知重启后的Main System 发生过什么。
(3) 擦除MISC 分区中的BCB 数据块的内容,以便系统重启后不再进入Recovery 模式,而是进入更新后的主系统。
(4) 删除/cache/recovery/command 文件。这一步也是很重要的,因为重启后bootloader 会自动检索这个文件,如果未删除的话又会进入Recovery 模式。
11、根据在9步设置的after的值对手机的后续操作进行设定
switch (after) {
case Device::SHUTDOWN:
ui->Print("Shutting down...\n");
property_set(ANDROID_RB_PROPERTY, "shutdown,");
break;
case Device::REBOOT_BOOTLOADER:
ui->Print("Rebooting to bootloader...\n");
property_set(ANDROID_RB_PROPERTY, "reboot,bootloader");
break;
default:
ui->Print("Rebooting...\n");
property_set(ANDROID_RB_PROPERTY, "reboot,");
break;
}
最后手机进行关机或者重启或者reboot bootloader模式
从上层进入recovery服务
在setting-->备份与重置--->恢复出厂设置--->重置手机--->手机关机--->开机--->进行恢复出厂的操作--->开机流程。
恢复出厂设置其实是擦除用户数据分区,同时删除缓存区。在系统设置中选择“恢复出厂设置”选项后, APK 会发出一个广播:“android.intent.action.MASTER_CLEAR”,接收者是MasterClearReceiver 类,在收到广播之后会开启一个新线程:
public void onReceive(final Context context, final Intent intent) {
……
// The reboot call is blocking, so we need to do it on another thread.
Thread thr = new Thread("Reboot") {
@Override
public void run() {
try {
RecoverySystem.rebootWipeUserData(context, shutdown, reason);
Log.wtf(TAG, "Still running after master clear?!");
} catch (IOException e) {
Slog.e(TAG, "Can't perform master clear/factory reset", e);
} catch (SecurityException e) {
Slog.e(TAG, "Can't perform master clear/factory reset", e);
}
}
};
thr.start();
}
线程中调用了\frameworks\base\core\java\android\os\RecoverySystem.java类的rebootWipeUserData方法:
public static void rebootWipeUserData(Context context, boolean shutdown, String reason) throws IOException {
UserManager um = (UserManager) context.getSystemService(Context.USER_SERVICE);
if (um.hasUserRestriction(UserManager.DISALLOW_FACTORY_RESET)) {
throw new SecurityException("Wiping data is not allowed for this user.");
}
final ConditionVariable condition = new ConditionVariable();
Intent intent = new Intent("android.intent.action.MASTER_CLEAR_NOTIFICATION");
intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);
context.sendOrderedBroadcastAsUser(intent, UserHandle.OWNER,
android.Manifest.permission.MASTER_CLEAR,
new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
condition.open();
}
}, null, 0, null, null);
// Block until the ordered broadcast has completed.
condition.block();
String shutdownArg = null;
if (shutdown) {
shutdownArg = "--shutdown_after";
}
String reasonArg = null;
if (!TextUtils.isEmpty(reason)) {
reasonArg = "--reason=" + sanitizeArg(reason);
}
final String localeArg = "--locale=" + Locale.getDefault().toString();
bootCommand(context, shutdownArg, "--wipe_data", reasonArg, localeArg);
}
最终调用bootCommand(context, shutdownArg, "--wipe_data", reasonArg, localeArg);完成擦除数据的操作
bootCommand()函数分析:
/**重启进入recovery系统同时传入提供的参数*/
private static void bootCommand(Context context, String... args) throws IOException {
RECOVERY_DIR.mkdirs(); // In case we need it
COMMAND_FILE.delete(); // In case it's not writable
LOG_FILE.delete();
FileWriter command = new FileWriter(COMMAND_FILE);
//将参数逐行写入command文件中
try {
for (String arg : args) {
if (!TextUtils.isEmpty(arg)) {
command.write(arg);
command.write("\n");
}
}
} finally {
command.close();
}
// 写入cache/recovery/command文件中后,继续执行reboot的后续操作
PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
//这里执行reboot操作进入recovery模式
pm.reboot(PowerManager.REBOOT_RECOVERY);
throw new IOException("Reboot failed (no permissions?)");
}
这里进入recovery模式的入口在于: frameworks\base\core\java\android\os\PowerManager.java
public void reboot(String reason) {
try {
mService.reboot(false, reason, true);
} catch (RemoteException e) {
}
}
IPowerManager.aidl文件中的方法如下:
void reboot(boolean confirm, String reason, boolean wait);
其中对应的实现位于PowerManagerService.java中的内部类BinderService中:
private final class BinderService extends IPowerManager.Stub {
……
@Override // Binder call
public void reboot(boolean confirm, String reason, boolean wait) {
mContext.enforceCallingOrSelfPermission(android.Manifest.permission.REBOOT, null);
if (PowerManager.REBOOT_RECOVERY.equals(reason)) {
mContext.enforceCallingOrSelfPermission(android.Manifest.permission.RECOVERY, null);
}
final long ident = Binder.clearCallingIdentity();
try {
shutdownOrRebootInternal(false, confirm, reason, wait);
} finally {
Binder.restoreCallingIdentity(ident);
}
}
……
}
bootCommand()经过如下调用后最终到调用到本地JNI 接口rebootNative(),就是\frameworks\base\core\jni\android_os_Power.cpp 中的android_os_Power_reboot 函数。
具体的调用流程如下:
该函数继续调用\system\core\libcutils\android_reboot.c 中的int android_reboot(int cmd, int flags UNUSED, char *arg),该函数根据第一个参数的不同走向不同的分支,
switch (cmd) {
case ANDROID_RB_RESTART:
ret = reboot(RB_AUTOBOOT);
break;
case ANDROID_RB_POWEROFF:
ret = reboot(RB_POWER_OFF);
break;
case ANDROID_RB_RESTART2:
ret = syscall(__NR_reboot,LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART2, arg);
break;
default:
ret = -1;
}
相关宏定义见\kernel\include\linux\reboot.h。在reboot.h中定义的函数实现在kernel/kernel/sys.c中的函数 SYSCALL_DEFINE4():为了避免误操作而进入 recovery模式,该函数首先检测所谓的魔法参数,之后判断启动命令,如果是 LINUX_REBOOT_CMD_RESTART2,表示用所给的命令字符串重启系统。调用关系如下:
可以看出,虽然经过了层层调用,但始终有一个内容为“recovery”的字符串参数没有被丢弃过,最后传给了arch_reset(mode, cmd),最终在这里使用:
可以看到,当参数为“recovery”时,会给restart_reason 地址处写入0x77665502。
在代码里有:
45: #define RESTART_REASON_ADDR 0x65C
247: restart_reason = MSM_IMEM_BASE + RESTART_REASON_ADDR;
在\kernel\arch\arm\mach-msm\include\mach\msm_iomap-8x60.h 中有
所以restart_reason 的实际物理地址是0x2A05F000+0x65C =0x2A05F65C,在之前讲到手机启动时, check_reboot_mode 函数会检测SMEM 中的reboot_mode 变量值以判断进入何种工作方式,该函数中读取内存地址0x2A05F65C,这正是arch_reset 函数写入restart_reason 的地址。这样调用pm.reboot(“recovery”) 函数后,最终实现了重启后进入recovery 模式。
相关推荐
本学习总结涵盖了Oracle的入门知识、全套命令及SQL语法,旨在为初学者提供全面的学习材料。以下是对这些主题的详细阐述: 一、Oracle入门总结 Oracle数据库的基本概念包括数据库实例、表空间、数据文件、控制文件、...
总结,刷机Recovery是一项涉及系统级别的操作,需要谨慎对待。通过正确的步骤和合适的Recovery文件,可以极大地扩展设备的功能和自定义程度,但也需要注意操作安全,避免造成不必要的损失。在刷机过程中,不断学习和...
【ignite实验学习总结】 本文将对使用HP UX操作系统下的ignite技术进行系统分发的实验进行总结,该实验在BL860刀片服务器上进行,软件环境为HPUX 11.31。Ignite是一款高效的数据保护和恢复工具,尤其适用于分布式...
Veritas System Recovery 16 是一款强大的数据保护和灾难恢复解决方案,专为Windows环境设计。该软件提供了全面的系统恢复能力,旨在帮助企业迅速从意外的数据丢失或系统故障中恢复。以下是对这款产品安装使用的一些...
### ORACLE数据库学习总结 #### 一、数据库简介与安装 **1、Oracle与SQL Server比较的优点:** - **跨平台支持:** Oracle支持多种操作系统平台,如Windows、Linux、Unix等,而SQL Server主要支持Windows系统。这...
这篇文档《Oracle数据库学习日记实用性最强的Oracle学习总结》旨在为初学者提供一个全面而实用的学习指南,涵盖从基础使用到高级管理的多个方面。 **1. 基本使用** 1.1 常用命令 Oracle数据库的日常操作涉及多种...
以下是对Oracle数据库学习要点的详细总结: 1. **语法差异**:从SQL Server转换到Oracle,首先要适应的是语法上的变化。例如,Oracle中参数赋值需使用`:`前缀,如`Parameter := 5;`,且语句结尾必须加分号。此外,...
Oracle学习是一个持续的过程,涉及到众多的概念和技术。通过不断实践和深入研究,才能真正掌握Oracle的精髓,成为一名熟练的数据库管理员或开发人员。在学习过程中,结合实际案例和实验环境,将理论知识与实际操作相...
Oracle的学习与总结涵盖了多个方面,包括基础概念、安装配置、SQL语言、表空间管理、索引、触发器、存储过程、数据库安全、备份恢复、性能优化等关键知识点。 一、基础概念 Oracle数据库的核心概念包括实例...
### 知识点总结 #### 一、VMware Site Recovery Manager 5.0 概述 - **产品定位**:VMware Site Recovery Manager (SRM) 是一款专注于灾难恢复解决方案的产品,它为虚拟化环境提供了自动化且可靠的业务连续性策略...
总结来说,Advanced PDF Password Recovery是一款功能强大、易用性强的PDF密码恢复工具,尤其适合那些经常处理受保护PDF文档的用户。无论是个人还是企业,都可以通过这款软件解决忘记PDF密码的问题,保障工作或学习...
总结来说,"picture-recovery.rar_NewDIB_遗传算法"提供了一个结合遗传算法与图像处理技术的实践案例,展示了如何运用这些工具进行复杂问题的求解。通过学习和理解这个项目,开发者不仅可以掌握遗传算法的基本原理,...
《IHT在压缩感知中的应用详解》 压缩感知(Compressive Sensing,简称CS)是一种新兴的信号处理技术,它...同时,对“CS_IHT_recovery.m”的深入学习有助于我们更好地理解和运用这一技术,为信号处理提供有力工具。
- **AIX安装**: 介绍了AIX操作系统的安装流程,帮助用户快速部署AIX环境。 - **系统备份**: 讲解了如何对AIX系统进行备份,以防止数据丢失或系统故障带来的损失。 #### 部分内容中的知识点解析: **第1章 认证概述...
在神经网络驱动的文本生成领域,李家宁等人提出了一个创新性的方法——差异化分布恢复(Differentiated Distribution Recovery, DDR),旨在提升模型生成文本的质量,同时解决传统方法存在的问题。本文将深入探讨DDR...
Xavier NX作为一款高性能的嵌入式计算平台,被广泛应用于机器学习、计算机视觉等前沿领域。初次使用时,用户通常需要进行刷机操作来配置系统环境。本文档详细介绍了Xavier NX开箱后的首次刷机流程,确保设备能够顺利...
首先,"全是我自己做的笔记,供大家一起分享和探讨.txt"可能包含个人在学习Oracle过程中的理解和实践总结,包括基础的SQL语法、数据类型、表的创建与管理、索引、视图等。个人笔记往往带有作者独特的见解,能提供...
Oracle SQL是数据库管理员(DBA)和SQL开发者在管理Oracle数据库时不可或缺的工具。这篇文档集将为你提供全面的Oracle SQL知识,涵盖了从...这份"Oracle sql文总结,Dba学习资料,sql开发大全"正是你成长的宝贵财富。