一、我们从上一篇已经知道整个update_engine的核心就是UpdateAttempterAndroid，那我们就接着来看UpdateAttempterAndroid都做了写什么事。
我们知道BinderUpdateEngineAndroidService的核心方法就是applyPayload()，而BinderUpdateEngineAndroidService :: applyPayload()的内部又调用的是UpdateAttempterAndroid的applyPayload()，这里就主要分析UpdateAttempterAndroid::applyPayload();

这里先把update.zip的内容展示一下

还是从分析代码开始：

system/update_engine/update_attempter_android.cc
void UpdateAttempterAndroid::Init() {// In case of update_engine restart without a reboot we need to restore the// reboot needed state.if (UpdateCompletedOnThisBoot()) { // 这里有一种case就是如果在升级下载刚完成时，update_engine程序挂掉了，但是机器并没有关机，update_engine被再次拉起，就先会去判断是否上次整个下载写入分区完成，如果完成就直接通知重启机器，SetStatusAndNotify(UpdateStatus::UPDATED_NEED_REBOOT);} else { if (!boot_control_->MarkBootSuccessfulAsync(Bind([](bool successful){}))) {LOG(WARNING) << "clear boot_control tries_remaining failed ";}SetStatusAndNotify(UpdateStatus::IDLE); // 如果不是上面的那种情况就进去空闲模式UpdatePrefsAndReportUpdateMetricsOnReboot();}
}bool UpdateAttempterAndroid::ApplyPayload(const string& payload_url, //升级文件的file或者http 路径int64_t payload_offset,   // paylood.bin文件在update.zip中的偏移量int64_t payload_size,    // paylood.bin的大小const vector<string>& key_value_pair_headers, // payload_properties.txt的内容 如下/* FILE_HASH=3iyIhAclW0+nST5m6IcOHjcBJdqltnSjUpC00rH/QDM=FILE_SIZE=537106805METADATA_HASH=7G5qkHiV//xB07FfNBOJ65diSCgLeb46dTZctkoMydg=METADATA_SIZE=57962 */brillo::ErrorPtr* error) {// 一进来还是先判断是否上次升级完成了if (status_ == UpdateStatus::UPDATED_NEED_REBOOT) { return LogAndSetError(error, FROM_HERE, "An update already applied, waiting for reboot");}// 如果当前一个升级正在继续就取消这次升级任务if (ongoing_update_) { return LogAndSetError(error, FROM_HERE, "Already processing an update, cancel it first.");}//确保ApplyPayload进来update_engine是空闲状态DCHECK(status_ == UpdateStatus::IDLE); std::map<string, string> headers;// 解析payload_properties.txt的内容for (const string& key_value_pair : key_value_pair_headers) { string key;string value;if (!brillo::string_utils::SplitAtFirst(key_value_pair, "=", &key, &value, false)) {return LogAndSetError(error, FROM_HERE, "Passed invalid header: " + key_value_pair);}if (!headers.emplace(key, value).second)return LogAndSetError(error, FROM_HERE, "Passed repeated key: " + key);}// Unique identifier for the payload. An empty string means that the payload// can't be resumed.//// payload_id 的到 FILE_HASH和METADATA_HASHstring payload_id = (headers[kPayloadPropertyFileHash] +headers[kPayloadPropertyMetadataHash]); // Setup the InstallPlan based on the request.// 使用传入的参数构建install_plan_install_plan_ = InstallPlan();install_plan_.download_url = payload_url;install_plan_.version = "";// set base_offset for libcur or fileHttp, base_offset is payload Offset in update.zipbase_offset_ = payload_offset;InstallPlan::Payload payload;payload.size = payload_size;if (!payload.size) {if (!base::StringToUint64(headers[kPayloadPropertyFileSize],&payload.size)) {payload.size = 0;}}if (!brillo::data_encoding::Base64Decode(headers[kPayloadPropertyFileHash],&payload.hash)) {LOG(WARNING) << "Unable to decode base64 file hash: "<< headers[kPayloadPropertyFileHash];}if (!base::StringToUint64(headers[kPayloadPropertyMetadataSize],&payload.metadata_size)) {payload.metadata_size = 0;}// The |payload.type| is not used anymore since minor_version 3.// 默认升级包的类型为 kUnknownpayload.type = InstallPayloadType::kUnknown;install_plan_.payloads.push_back(payload);// The |public_key_rsa| key would override the public key stored on disk.install_plan_.public_key_rsa = "";install_plan_.hash_checks_mandatory = hardware_->IsOfficialBuild();install_plan_.is_resume = !payload_id.empty() &&DeltaPerformer::CanResumeUpdate(prefs_, payload_id);if (!install_plan_.is_resume) {if (!DeltaPerformer::ResetUpdateProgress(prefs_, false)) {LOG(WARNING) << "Unable to reset the update progress.";}if (!prefs_->SetString(kPrefsUpdateCheckResponseHash, payload_id)) {LOG(WARNING) << "Unable to save the update check response hash.";}}// 标记要升级的slot为target_slot install_plan_.source_slot = boot_control_->GetCurrentSlot();install_plan_.target_slot = install_plan_.source_slot == 0 ? 1 : 0;install_plan_.powerwash_required =GetHeaderAsBool(headers[kPayloadPropertyPowerwash], false);install_plan_.switch_slot_on_reboot =GetHeaderAsBool(headers[kPayloadPropertySwitchSlotOnReboot], true);install_plan_.run_post_install = true;// Optionally skip post install if and only if:// a) we're resuming// b) post install has already succeeded before// c) RUN_POST_INSTALL is set to 0.if (install_plan_.is_resume && prefs_->Exists(kPrefsPostInstallSucceeded)) {bool post_install_succeeded = false;prefs_->GetBoolean(kPrefsPostInstallSucceeded, &post_install_succeeded);if (post_install_succeeded) {install_plan_.run_post_install =GetHeaderAsBool(headers[kPayloadPropertyRunPostInstall], true);}}NetworkId network_id = kDefaultNetworkId;if (!headers[kPayloadPropertyNetworkId].empty()) {if (!base::StringToUint64(headers[kPayloadPropertyNetworkId],&network_id)) {return LogAndSetError(error,FROM_HERE,"Invalid network_id: " + headers[kPayloadPropertyNetworkId]);}if (!network_selector_->SetProcessNetwork(network_id)) {return LogAndSetError(error,FROM_HERE,"Unable to set network_id: " + headers[kPayloadPropertyNetworkId]);}}LOG(INFO) << "Using this install plan:";install_plan_.Dump(); // 这是我打出来的log, InstallPlan: new_update, version: , source_slot: A, target_slot: B, url: http://10.16.17.170:8080/downloads/ota_update.zip, payload: (size: 537106805, metadata_size: 57962, metadata signature: , hash: DE2C888407255B4FA7493E66E8870E1E370125DAA5B674A35290B4D2B1FF4033, payload type: unknown), hash_checks_mandatory: true, powerwash_required: false, switch_slot_on_reboot: true, run_post_install: trueBuildUpdateActions(payload_url); // 1.1 解析如下// Setup extra headers.HttpFetcher* fetcher = download_action_->http_fetcher();if (!headers[kPayloadPropertyAuthorization].empty())fetcher->SetHeader("Authorization", headers[kPayloadPropertyAuthorization]);if (!headers[kPayloadPropertyUserAgent].empty())fetcher->SetHeader("User-Agent", headers[kPayloadPropertyUserAgent]);SetStatusAndNotify(UpdateStatus::UPDATE_AVAILABLE); //1.2 解析如下ongoing_update_ = true;// Just in case we didn't update boot flags yet, make sure they're updated// before any update processing starts. This will start the update process.UpdateBootFlags(); //1.3 解析如下UpdatePrefsOnUpdateStart(install_plan_.is_resume);// TODO(xunchang) report the metrics for unresumable updatesreturn true;
}

Action的类图

1.1 这里面主要做的就是构建四个action然后将这四个action set到ActionProcessor的 std::deque<AbstractAction*> actions_中。
void UpdateAttempterAndroid::BuildUpdateActions(const string& url) {// 检查ActionProcessor是否已经处于Running状态CHECK(!processor_->IsRunning());//将自己设置为ActionProcessor的代理对象，ActionProcessor只需要通过代理对象就可以向外发送通知processor_->set_delegate(this);// Actions:// 构建 InstallPlanActionshared_ptr<InstallPlanAction> install_plan_action(new InstallPlanAction(install_plan_));HttpFetcher* download_fetcher = nullptr;if (FileFetcher::SupportedUrl(url)) { // 判断是url是 file还是httpDLOG(INFO) << "Using FileFetcher for file URL.";download_fetcher = new FileFetcher(); //url 是 file 就是FileFetcher负责read} else {
#ifdef _UE_SIDELOADLOG(FATAL) << "Unsupported sideload URI: " << url;
#elseLibcurlHttpFetcher* libcurl_fetcher =new LibcurlHttpFetcher(&proxy_resolver_, hardware_); // url是http LibcurlHttpFetcher负责下载libcurl_fetcher->set_server_to_check(ServerToCheck::kDownload);download_fetcher = libcurl_fetcher;
#endif  // _UE_SIDELOAD}// 构建 DownloadActionshared_ptr<DownloadAction> download_action(new DownloadAction(prefs_,boot_control_,hardware_,nullptr,           // system_state, not used.download_fetcher,  // passes ownershiptrue /* is_interactive */));//构建 FilesystemVerifierActionshared_ptr<FilesystemVerifierAction> filesystem_verifier_action(new FilesystemVerifierAction());//构建 PostinstallRunnerActionshared_ptr<PostinstallRunnerAction> postinstall_runner_action(new PostinstallRunnerAction(boot_control_, hardware_));download_action->set_delegate(this);download_action->set_base_offset(base_offset_);download_action_ = download_action;postinstall_runner_action->set_delegate(this);// 将四个action都set到ActionProcessor的 std::deque<AbstractAction*> actions_中。actions_.push_back(shared_ptr<AbstractAction>(install_plan_action));actions_.push_back(shared_ptr<AbstractAction>(download_action));actions_.push_back(shared_ptr<AbstractAction>(filesystem_verifier_action));actions_.push_back(shared_ptr<AbstractAction>(postinstall_runner_action));// Bond them together. We have to use the leaf-types when calling// BondActions().//通过ActionPipe将4个Action连接起来，前面action的结果作为输入到下一个action。BondActions(install_plan_action.get(), download_action.get());BondActions(download_action.get(), filesystem_verifier_action.get());BondActions(filesystem_verifier_action.get(),postinstall_runner_action.get());// Enqueue the actions.//将Action添加到ActionProcessor的管理队列中for (const shared_ptr<AbstractAction>& action : actions_)processor_->EnqueueAction(action.get());
}

SetStatusAndNotify的通知时序图

1.2 通过 SetStatusAndNotify通知到 BinderUpdateEngineAndroidService再通知到UI

void UpdateAttempterAndroid::SetStatusAndNotify(UpdateStatus status) {status_ = status;size_t payload_size =install_plan_.payloads.empty() ? 0 : install_plan_.payloads[0].size;UpdateEngineStatus status_to_send = {.status = status_,.progress = download_progress_,.new_size_bytes = payload_size};for (auto observer : daemon_state_->service_observers()) {observer->SendStatusUpdate(status_to_send); //通知 BinderUpdateEngineAndroidService::SendStatusUpdate（）}last_notify_time_ = TimeTicks::Now();
}

1.3 UpdateBootFlags 从这个后面就会走到actionProcess中去，具体执行内容是在ActionProcess中的调用。
见整体调用时序图，黑框内的。

void UpdateAttempterAndroid::UpdateBootFlags() {if (updated_boot_flags_) { //是否成功调用过boot_control_-> MarkBootSuccessfulAsync()标记当前slotLOG(INFO) << "Already updated boot flags. Skipping.";CompleteUpdateBootFlags(true);return;}// This is purely best effort.LOG(INFO) << "Marking booted slot as good.";if (!boot_control_->MarkBootSuccessfulAsync(Bind(&UpdateAttempterAndroid::CompleteUpdateBootFlags,base::Unretained(this)))) {LOG(ERROR) << "Failed to mark current boot as successful.";CompleteUpdateBootFlags(false);}
}

二，action机制。
在UpdateAttempterAndroid中重点就是Action机制
2.1、Action机制：
Action机制主要有三个部分组成: Action, ActionProcessor和ActionPipe
2.1.1 Action
基于Action机制，Update Engine里面的每一个任务都被封装为一个Action，在UpdateAttempterAndroid中大致分为是三个任务段，1、DownloadAction 主要负责下载数据和写入数据到相应的分区。 2 、FilesystemVerifierAction主要负责验证写入的数据hash值和下载包里面带的原有的hash值是否有差别。3、PostinstallRunnerAction 更新完成后所有收尾动作。但是还有一个Action InstallPlanAction，其实这个action没有具体的大任务，就是负责第一个传递install_plan_这个对象，暂且这么理解吧。

2.1.2、ActionProcessor
在ActionProcessor里面定义了一个Action的队列, 在Update Engine准备更新时，会根据当前传入的参数构造多个Action并放入ActionProcessor的Action队列，除了Action队列，ActionProcessor中还有一个指针，用于指示当前正在运行的ActionActionProcessor通过StartProcessing()操作开始工作，先挑选队列中的第一个Action作为当前Action。然后当前Action调用，PerformAction()开始工作，Action结束后会调用ActionProcessor的ActionComplete()接口通知当前Action已经完成。随后ActionProcessor通过StartNextActionOrFinish()挑选队列中的下一个Action进行操作。循环往复，直到队列中的所有Action都完成操作。

2.1.3 Action pipe
类似于Unix系统的管道，Action机制中，也会通过管道ActionPipe将这些Action链接在一起。上一个Action的输出会作为下一个Action的输入，因此在Update Engine中，所有的Action之间有一个先后关系。例如，只有DownloadAction完成操作了，才能开始FilesystemVerifierAction操作；也只有FilesystemVerifierAction结束了，才会开始PostinstallRunnerAction操作。

总结：从上面我们知道了UpdateAttempterAndroid的核心又是四个action的具体任务，并且四个action是通过action机制进行管理的每一个action的执行结果都作为参数传递给后一个action。