由于客户不使用外网升级系统，就要公司自己做升级系统的功能；由于第一次做走了不少的坑，好记性不如烂笔头，以此记录，谨防遗忘。此流程对于MTK M代码使用的详情，其他仅供参考。
思路大概流程：通过做一个升级的APP，负责下载系统生成的差分包，APP把下载的差分包下载到指定的目录（data/data/cache），recovery系统检测升级。
一、系统层：首先，系统利用Google原生OTA升级recovery系统进行升级包的制作。
操作步骤如下：
1、首先，修改完功能之后，make整个工程生成ROM包
2、紧接着执行命令：make otapackage 制作出可做差分的全量包：out\target\product\xxxxxxx\obj\PACKAGING\target_files_intermediates/，的包拷出来，任意命为自己想要的名字如V1_full_target.zip；再把高版本的相同路径的文件同样操作，放到根目录下，
3、执行以下命令，即可生成差分包target.zip
6.0制作ota命令：
./build/tools/releasetools/ota_from_target_files -s device/mediatek/build/releasetools/mt_ota_from_target_files.py -i V1_full_target.zip V2_full_target.zip target.zip
8.1制作ota命令：
./build/tools/releasetools/ota_from_target_files -s vendor/mediatek/proprietary/scripts/releasetools/mt_ota_from_target_files -i ota/v1.zip ota/v2.zip update.zip
9.0制作ota命令：
./build/tools/releasetools/ota_from_target_files -i ota/V1_full_target.zip ota/V2_full_target.zip new_target.zip 注意：当执行以上命令时，如果编译的版本1.0在1.1之后就会报以下时间戳的代码错误，因此解决的办法就是按照顺序编译需要的版本信息，不能贪图时间上的迅速，而忽视细节上的问题。
RuntimeError: Downgrade detected based on timestamp check: pre: 1587451941, post: 1586940689. Need to specify --override_timestamp OR --downgrade to allow building the incremental.在修改系统之前，可能会碰到APP进入recovery模式之后，不能自动跳转升级的状况，这就要修bootable/recovery/mt_recovery.cpp的文件，跳转到升级的状态，再重启。
--- a/alps/bootable/recovery/mt_recovery.cpp
+++ b/alps/bootable/recovery/mt_recovery.cpp
@@ -601,16 +601,19 @@ mt_prompt_and_wait(Device* device, int status) {
modified_flash = true;
if (mt_prompt_and_wait_install(device, status, CACHE_ROOT, SDCARD_ROOT, wipe_cache, "sdcard", ret, 0))
return ret;
+ return Device::REBOOT;
break;
#if defined(SUPPORT_SDCARD2) && !defined(MTK_SHARED_SDCARD) //wschen 2012-11-15
case Device::APPLY_SDCARD2:
if (mt_prompt_and_wait_install(device, status, CACHE_ROOT, SDCARD2_ROOT, wipe_cache, "sdcard2", ret, 0))
return ret;
+ return Device::REBOOT;
break;
#endif
case Device::APPLY_CACHE:
if (mt_prompt_and_wait_install(device, status, NULL, CACHE_ROOT, wipe_cache, "cache", ret, 0))
return ret;
+ return Device::REBOOT;
break;
case Device::READ_RECOVERY_LASTLOG:
choose_recovery_file(device);二、APP层问题点重现：
再做APP的时候，有时候可能会出现标题上面的错误。
首先，分析的是权限的问题，因为错误明显说是权限错误，可是下载下来之后，就是不能升级。因为是把OTA升级APP内置到系统里面，考虑不用签名就行了，这是第一个问题点所在。
其次，一般APP都是内置到system/app下的，所以就随便就内置进去，没考虑到这个问题点。因系统级的权限才能执行recovery模式的操作。
总之，对于APP来说，OTA升级APP需要：1、签名；2、系统内置app要到system/priv/app下使APP申请到系统的权限；3、APP保证下载目录要正确（data/data/cache）
PS：当时在验证流程的时候，利用adb命令（adb reboot recovery）进入recovery模式，进入之后就是倒地的小机器人，搞得焦头烂额，找不着头脑。后来才发现是android机制的私密保护机制。以下是FAQ解释：
[DESCRIPTION]
客户发现使用user load进入recovery mode，没有办法正常显示recovery界面。
而是出现一个倒地的小机器人，并提示“no cmd”：
但是使用userdebug版本，却是正常的！
[SOLUTION]
使用内部版本测试，会发现跟客户现象完全相同。
这并不是user版本的bug，而是特意这样设计的：
刷机之后，进入reccovery mode，会显示no cmd.
对User版本(非debug版本)有这样的设计，主要是为了提醒终端用户不要随意进入recovery mode，以及不要随意在recovery mode进行操作，以防引起问题。
User版本，如果需要进入正常recovery界面，操作如下：
刷机之后，进入reccovery mode，显示no cmd；
然后再按power键，以及音量上键，才能进入正常recovery界面.