189 8069 5689
目录
创新互联建站专业为企业提供桥东网站建设、桥东做网站、桥东网站设计、桥东网站制作等企业网站建设、网页设计与制作、桥东企业网站模板建站服务，十载桥东做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。
许多编程语言都有一个特殊的函数，当操作系统开始运行程序时会自动执行该函数。这个函数通常被命名为main()，并且依据语言标准具有特定的返回类型和参数。另一方面，Python解释器从文件顶部开始执行脚本，并且没有自动执行的特殊函数。
尽管如此，为程序的执行定义一个起始点有助于理解程序是如何运行的。Python程序员提出了几种方式对此进行实现。
本文结束时，您将了解以下内容：
Python中的基本main()函数
一些Python脚本中，包含一个函数定义和一个条件语句，如下所示：
此代码中，包含一个main()函数，在程序执行时打印Hello World!。此外，还包含一个条件（或if）语句，用于检查__name__的值并将其与字符串"__main__"进行比较。当if语句为True时，Python解释器将执行main()函数。更多关于Python条件语句的信息可以由此获得。
这种代码模式在Python文件中非常常见，它将作为脚本执行并导入另一个模块。为了帮助理解这段代码的执行方式，首先需要了解Python解释器如何根据代码的执行方式设置__name__。
Python中的执行模式
Python解释器执行代码有两种方式：
更多内容可参考如何运行Python脚本。无论采用哪种方式，Python都会定义一个名为__name__的特殊变量，该变量包含一个字符串，其值取决于代码的使用方式。
本文将如下示例文件保存为execution_methods.py，以 探索 代码如何根据上下文改变行为：
在此文件中，定义了三个对print()函数的调用。前两个打印一些介绍性短语。第三个print()会先打印短语The value __name__ is，之后将使用Python内置的repr()函数打印出__name__变量。
在Python中，repr()函数将对象转化为供解释器读取的形式。上述示例通过使用repr()函数来强调__name__的值为字符串。更多关于repr()的内容可参考Python文档。
在本文中，您将随处可见文件(file)，模块(module)和脚本(script)这三个字眼。实际上，三者之间并无太大的差别。不过，在强调代码目的时，还是存在细微的差异：
“如何运行Python脚本”一文也讨论了三者的差别。
基于命令行执行
在这类方法中，Python脚本将通过命令行来执行。
执行脚本时，无法与Python解释器正在执行的代码交互。关于如何通过命令行执行代码的详细信息对本文而言并不重要，但您可以通过展开下框阅读更多有关Windows，Linux和macOS之间命令行差异的内容。
命令行环境
不同的操作系统在使用命令行执行代码时存在细微的差异。
在Linux和macOS中，通常使用如下命令：
美元符号($)之前的内容可能有所不同，具体取决于您的用户名和计算机名称。您键入的命令位于$之后。在Linux或macOS上，Python3的可执行文件名为python3，因此可以通过输入python3 script_name.py来运行python脚本。
在Windows上，命令提示符通常如下所示：
根据您的用户名，之前的内容可能会有所不同，您输入的命令位于之后。在Windows上，Python3的可执行文件通常为python。因此可以通过输入python script_name.py来运行python脚本。
无论哪种操作系统，本文的Python脚本的输出结果都是相同的。因此本文以Linux和macOS为例。
使用命令行执行execution_methods.py，如下所示：
在这个示例中，__name__具有值'__main__'，其中引号(')表明该值为字符串类型。
请记住，在Python中，使用单引号(')和双引号(")定义的字符串没有区别。更多关于字符串的内容请参考Python的基本数据类型。
如果在脚本中包含"shebang行"并直接执行它(./execution_methods.py)，或者使用IPython或Jupyter Notebook的%run，将会获取相同的结果。
您还可以通过向命令行添加-m参数的方法实现以模块的方式执行。通常情况下，推荐如下方式pip: python3 -m pip install package_name。
添加-m参数将会运行包中__main__.py的代码。更多关于__main__.py文件的内容可参考如何将开源Python包发布到PyPI中。
在三种情况中，__name__都具有相同的值：字符串'__main__'。
技术细节：Python文档中具体定义了__name__何时取值为'__main__'。
当通过标准输入，脚本或者交互提示中读取数据时，模块的__name__将取值为'__main__'。（来源）
__name__与__doc__，__package__和其他属性一起存储在模块的全局命名空间。更多关于属性的信息可参考Python数据模型文档，特别是关于模块和包的信息，请参阅Python Import文档。
导入模块或解释器
接下来是Python解释器执行代码的第二种方式：导入。在开发模块或脚本时，可以使用import关键字导入他人已经构建的模块。
在导入过程中，Python执行指定模块中定义的语句（但仅在第一次导入模块时）。要演示导入execution_methods.py文件的结果，需要启动Python解释器，然后导入execution_methods.py文件：
在此代码输出中，Python解释器执行了三次print()函数调用。前两行由于没有变量，在输出方面与在命令行上作为脚本执行时完全相同。但是第三个输出存在差异。
当Python解释器导入代码时，__name__的值与要导入的模块的名称相同。您可以通过第三行的输出了解这一点。__name__的值为'execution_methods'，是Python导入的.py文件。
注意如果您在没有退出Python时再次导入模块，将不会有输出。
注意：更多关于导入在Python中如何工作的内容请参考官方文档和Python中的绝对和相对导入。
Main函数的最佳实践
既然您已经了解两种执行方式上的差异，那么掌握一些最佳实践方案还是很有用的。它们将适用于编写作为脚本运行的代码或者在另一个模块导入的代码。
如下是四种实践方式：
将大部分代码放入函数或类中
请记住，Python解释器在导入模块时会执行模块中的所有代码。有时如果想要实现用户可控的代码，会导致一些副作用，例如：
在这种情况下，想要实现用户控制触发此代码的执行，而不是让Python解释器在导入模块时执行代码。
因此，最佳方法是将大部分代码包含在函数或类中。这是因为当Python解释器遇到def或class关键字时，它只存储这些定义供以后使用，并且在用户通知之前不会实际执行。
将如下代码保存在best_practices.py以证明这个想法：
在此代码中，首先从time模块中导入sleep()。
在这个示例中，参数以秒的形式传入sleep()函数中，解释器将暂停一段时间再运行。随后，使用print()函数打印关于代码描述的语句。
之后，定义一个process_data()函数，执行如下五项操作：
在命令行中执行
当你将此文件作为脚本用命令行执行时会发生什么呢？
Python解释器将执行函数定义之外的from time import sleep和print()，之后将创建函数process_data()。然后，脚本将退出而不做任何进一步的操作，因为脚本没有任何执行process_data()的代码。
如下是这段脚本的执行结果：
我们在这里看到的输出是第一个print()的结果。注意，从time导入和定义process_data()函数不产生结果。具体来说，调用定义在process_data()内部的print()不会打印结果。
导入模块或解释器执行
在会话（或其他模块）中导入此文件时，Python解释器将执行相同的步骤。
Python解释器导入文件后，您可以使用已导入模块中定义的任何变量，类或函数。为了证明这一点，我们将使用可交互的Python解释器。启动解释器，然后键入import best_practices：
导入best_practices.py后唯一的输出来自process_data()函数外定义的print()。导入模块或解释器执行与基于命令行执行类似。
使用__name__控制代码的执行
如何实现基于命令行而不使用Python解释器导入文件来执行呢？
您可以使用__name__来决定执行上下文，并且当__name__等于"__main__"时才执行process_data()。在best_practices.py文件中添加如下代码：
这段代码添加了一个条件语句来检验__name__的值。当值为"__main__"时，条件为True。记住当__name__变量的特殊值为"__main__"时意味着Python解释器会执行脚本而不是将其导入。
条件语块内添加了四行代码（第12，13，14和15行）：
现在，在命令行中运行best_practices.py，并观察输出的变化：
首先，输出显示了process_data()函数外的print()的调用结果。
之后，data的值被打印。因为当Python解释器将文件作为脚本执行时，变量__name__具有值"__main__"，因此条件语句被计算为True。
接下来，脚本将调用process_data()并传入data进行修改。当process_data执行时，将输出一些状态信息。最终，将输出modified_data的值。
现在您可以验证从解释器（或其他模块）导入best_practices.py后发生的事情了。如下示例演示了这种情况：
注意，当前结果与将条件语句添加到文件末尾之前相同。因为此时__name__变量的值为"best_practices"，因此条件语句结果为False，Python将不执行process_data()。
创建名为main()的函数来包含要运行的代码
现在，您可以编写作为脚本由从命令行执行并导入且没有副作用的Python代码。接下来，您将学习如何编写代码并使其他程序员能轻松地理解其含义。
许多语言，如C，C++，Java以及其他的一些语言，都会定义一个叫做main()的函数，当编译程序时，操作系统会自动调用该函数。此函数通常被称为入口点(entry point)，因为它是程序进入执行的起始位置。
相比之下，Python没有一个特殊的函数作为脚本的入口点。实际上在Python中可以将入口点定义成任何名称。
尽管Python不要求将函数命名为main()，但是最佳的做法是将入口点函数命名为main()。这样方便其他程序员定位程序的起点。
此外，main()函数应该包含Python解释器执行文件时要运行的任何代码。这比将代码放入条件语块中更好，因为用户可以在导入模块时重复使用main()函数。
修改best_practices.py文件如下所示：
在这个示例中，定义了一个main()函数，它包含了上面的条件语句块。之后修改条件语块执行main()。如果您将此代码作为脚本运行或导入，将获得与上一节相同的输出。
在main()中调用其他函数
另一种常见的实现方式是在main()中调用其他函数，而不是直接将代码写入main()。这样做的好处在于可以实现将几个独立运行的子任务整合。
例如，某个脚本有如下功能：
如果在单独的函数中各自实现这些子任务，您（或其他用户）可以很容易地实现代码重用。之后您可以在main()函数中创建默认的工作流。
您可以根据自己的情况选择是否使用此方案。将任务拆分为多个函数会使重用更容易，但会增加他人理解代码的难度。
修改best_practices.py文件如下所示：
在此示例代码中，文件的前10行具有与之前相同的内容。第12行的第二个函数创建并返回一些示例数据，第17行的第三个函数模拟将修改后的数据写入数据库。
第21行定义了main()函数。在此示例中，对main()做出修改，它将调用数据读取，数据处理以及数据写入等功能。
首先，从read_data_from_web()中创建data。将data作为参数传入process_data()，之后将返回modified_data。最后，将modified_data传入write_data_to_database()。
脚本的最后两行是条件语块用于验证__name__，并且如果if语句为True，则执行main()。
在命令行中运行如下所示：
根据执行结果，Python解释器在执行main()函数时，将依次执行read_data_from_web()，process_data()以及write_data_to_database()。当然，您也可以导入best_practices.py文件并重用process_data()作为不同的数据输入源，如下所示：
在此示例中，导入了best_practices并且将其简写为bp。
导入过程会导致Python解释器执行best_practices.py的全部代码，因此输出显示解释文件用途的信息。
然后，从文件中存储数据而不是从Web中读取数据。之后，可以重用best_practices.py文件中的process_data()和write_data_to_database()函数。在此情况下，可以利用代码重写来取代在main()函数中实现全部的代码逻辑。
实践总结
以下是Python中main()函数的四个关键最佳实践：
结论
恭喜！您现在已经了解如何创建Python main()函数了。
本文介绍了如下内容：
现在，您可以开始编写一些非常棒的关于Python main()函数代码啦！
你可以使用rsa这个python库：
(bob_pub, bob_priv) = rsa.newkeys(512)
message = 'hello Bob!'
crypto = rsa.encrypt(message, bob_pub)
message = rsa.decrypt(crypto, bob_priv)
print message
hello Bob!
文档地址：
如果解决了您的问题请采纳！
如果未解决请继续追问
通过分析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服务的工作原理。另外详细分析其升级过程，对于我们在实际升级时，可以根据我们的需要做出相应的修改。
input("提示性信息")
如：
input("请输入数字")
因为 Python 没有特别人为规定数据类型，数据类型是由计算机进行判定，所以我们 input() 输入的数据均默认作为字符串处理，而如果要输入一些数字，着需要 eval() 评估函数对字符串进行评估，化为语句（数字）。
print(...)
默认空一行，如果想不空行，则
print(...., end = "")
特性：
进制：
特性：
浮点数间运算存在不确定尾数，不是 bug
如：0.1+0.3 → 0.4
0.1+0.2 → 0.30000000000000004
这是由于在计算机中一切数据都是化为二进制进行存储的，而有的浮点数并不能完全化为相等的二进制数，只能无限趋近于二进制数。
如：0.1 →
解决方法：
四舍五入：
例如：z = 1.23e-4 + 5.6e+89j
z.real 获得实部，z.imag 获得虚部
三种类型存在一种逐渐“扩展”或“变宽”的关系：
整数 → 浮点数 → 复数
特点：
字符串有 2 类共 4 种表示方法：
扩展：
使用[]获取字符串中一个或多个字符
使用[M:N:K]根据步长对字符串切片
{参数序号:格式控制标记}
右对齐
^ 居中对齐 | 槽设定的输出宽度 | 数字的千位分隔符 | 浮点数小数精度 或 字符串最大输出长度 | 整数类型
b , c , d , o , x , X
浮点数类型
e , E , f , % |
填充、对齐、宽度这三个一组，例如：
"{0:=^20}".format("PYTHON")
→ '=======PYTHON======='
"{0:*20}".format("BIT")
→ '*****************BIT'
"{:10}".format("BIT")
'BIT '
剩下的三个一组，例如：
"{0:,.2f}".format(12345.6789)
→ '12,345.68'
"{0:b},{0:c},{0:d},{0:o},{0:x},{0:X}x".format(425)
→ '110101001,Σ,425,651,1a9,1A9'
"{0:e},{0:E},{0:f},{0:%}".format(3.14)
'3.140000e+00,3.140000E+00,3.140000,314.000000%'
↓CloseCode↓
使用 raise 语句抛出一个指定的异常。
raise [Exception [, args [, traceback]]]
紧凑形式：适用于简单表达式的二分支结构
表达式1 if 条件 else 表达式2
例如：
↓CloseCode↓
↓CloseCode↓
↓CloseCode↓
↓CloseCode↓
例如：
↓CloseCode↓
运行结果：
↓CloseCode↓
↓CloseCode↓
例如：
↓CloseCode↓
运行结果：
↓CloseCode↓
↓CloseCode↓
例如：
↓CloseCode↓
运行结果：
↓CloseCode↓
↓CloseCode↓
例如：
↓CloseCode↓
运行结果：
↓CloseCode↓
↓CloseCode↓
例如：
↓CloseCode↓
运行结果：
↓CloseCode↓
由条件控制的循环运行方式
↓CloseCode↓
例如：
↓CloseCode↓
运行结果：
↓CloseCode↓
↓CloseCode↓
↓CloseCode↓
例如：
↓CloseCode↓
运行结果：
↓CloseCode↓
例如：
↓CloseCode↓
运行结果：
↓CloseCode↓
↓CloseCode↓
可选参数例如：
↓CloseCode↓
运行结果：
↓CloseCode↓
可变参数例如：
↓CloseCode↓
运行结果：
↓CloseCode↓
在函数定义中，经常会碰到 *args(arguments) 和作为参数 **kwargs(keyword arguments)。
（事实上在函数中，和才是必要的，args 和 kwargs 可以用其他名称代替）
*args 是指不定数量的非键值对参数。
**kwargs 是指不定数量的键值对参数。
*args 作为作为元组匹配没有指定参数名的参数。而 **kwargs 作为字典，匹配指定了参数名的参数。
*args 必须位于 **kwargs 之前。
args( 通常紧跟一个标识符，你会看到a或者args都是标识符)是python用于接收或者传递任意基于位置的参数的语法。当你接收到一个用这种语法描叙参数时（比如你在函数def语句中对函数签名使用了星号语法），python会将此标识符绑定到一个元祖，该元祖包含了所有基于位置的隐士的接收到的参数。当你用这种语法传递参数时，标识符可以被绑定到任何可迭代对象（事实上，它也可以是人和表达式，并不必须是一个标识符），只要这个表达式的结果是一个可迭代的对象就行。
**kwds(标识符可以是任意的，通常k或者kwds表示)是python用于接收或者传递任意基于位置的参数的语法。（python有时候会将命名参数称为关键字参数，他们其实并不是关键字--只是用他们来给关键字命名，比如pass,for或者yield，还有很多，不幸的是，这种让人疑惑的术语目前仍是这门语言极其文化根深蒂固的一个组成部分。）当你接收到用这种语法描叙的一个参数时（比如你在函数的def语句中对函数签名使用了双星号语法）python会将标识符绑定到一个字典，该字典包含了所有接收到的隐士的命名参数。当你用这种语法传递参数时，标识符只能被绑定到字典（我ID号I它也可以是表达式，不一定是一个标识符，只要这个表达式的结果是一个字典即可）。
当你在定义或调用一个函数的时候，必须确保a和k在其他所有参数之后。如果这两者同时出现，要将k放在a之后。
lambda函数返回函数名作为结果
↓CloseCode↓
例如：
↓CloseCode↓
运行结果：
↓CloseCode↓
谨慎使用lambda函数
从原理上可以这样处理：用私钥对一个数据进行签名，然后用公钥对这个签名进行验证。如果验证通过即可证明这对密钥对是匹配的。