mtk安卓ota包编译

㈠ 如何打包安卓手机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/proct/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/proct/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/proct/security/testkey.x509.pem
build/target/proct/security/testkey.pk8 。
我们用命令make otapackage制作生成的update.zip包是已签过名的，如果自己做update.zip包时必须手动对其签名。
具体的加密方法：$ java –jar gingerbread/out/host/linux/framework/signapk.jar –w gingerbread/build/target/proct/security/testkey.x509.pem gingerbread/build/target/proct/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/proct/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 plainprint?
# -----------------------------------------------------------------
# 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 plainprint?
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/proct/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/proct/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/proct/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 plainprint?
assert(!less_than_int(1331176658, getprop("ro.build.date.utc")));
assert(getprop("ro.proct.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服务的工作原理。另外详细分析其升级过程，对于我们在实际升级时，可以根据我们的需要做出相应的修改。

㈡ 手机方案公司需要在mtk工程源码编译后将apk预装到system/app目录下如何操作

在 Android 中，如果要使用系统限制的权限（比如 android.permission.WRITE_SECURE_SETTINGS），我们需要把程序安装到 /system/app/ 下。

下面以 SecureSetting.apk 为例，演示这个操作。需要准备一台已经获得 Root 权限的手机。

1、通过 USB 连接手机和电脑。

2、使用 adb 控制手机。

源码打印？

1. $ adb push SecureSetting.apk /sdcard/ // 上传要安装的文件，为安装做准备。
2. $ adb shell
3. $ su // 切换到 root 用户。如果没有获得 Root 权限，这一步不会成功。
4. # mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system // 让分区可写。
5. # cat /sdcard/SecureSetting.apk > /system/app/SecureSetting.apk // 这一步可以用 cp 实现，但一般设备中没有包含该命令。如果使用 mv 会出现错误：failed on '/sdcard/NetWork.apk' - Cross-device link。
6. # mount -o remount,ro -t yaffs2 /dev/block/mtdblock3 /system // 还原分区属性，只读。
7. # exit
8. $ exit

$ adb push SecureSetting.apk /sdcard/ // 上传要安装的文件，为安装做准备。
$ adb shell
$ su // 切换到 root 用户。如果没有获得 Root 权限，这一步不会成功。
# mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system // 让分区可写。
# cat /sdcard/SecureSetting.apk > /system/app/SecureSetting.apk // 这一步可以用 cp 实现，但一般设备中没有包含该命令。如果使用 mv 会出现错误：failed on '/sdcard/NetWork.apk' - Cross-device link。
# mount -o remount,ro -t yaffs2 /dev/block/mtdblock3 /system // 还原分区属性，只读。
# exit
$ exit

㈢ 如何给Android的OTA包添加校验标识

下面以（RK 的 Sofia3GR 方案）来分享一下给OTA添加校验标识经验。
1、首先必须要了解ota升级原理以及phony脚本， 这个我就不多说了，网上资料一大把。
2、给系统添加一个属性字段
Sofia3GR 添加属性字段是在device\rockchip\sofia3gr\sofia3gr.mk里面：我添加 ro.proct.author = TangYin 属性。
然后执行make installclean 、 make -j8 、 ./mkimage.sh SF_3GR-cars-mehome-mn34227.dtb ota 编译生成ota 包， 利用SD卡烧写 到板上。
在板上使用getprop 命令可以查看到， 也可cat /system/build.prop文件。

㈣ MTK 怎么把apk自带的so文件编译到rom里边

一般情况下，MTK 文档上面是有这个说明的，要把apk中的so文件，放到alpsvendormediatekckt72_wet_jb3artifactsout argetproctckt72_wet_jb3systemlib 里边。注释 ckt72_wet_jb3 是项目名字，但是这里会有一个Bug。就是当你不再用第三方apk的时候，这个so文件依旧会打包进去到rom里边，如果你累计的so文件过大的话，rom就会变大，会影响内存运行的。这个时候，我们要想一个办法解决才行。

如图所示 建立这样的目录。lib里边放的是apk里边的so文件，Android.mk文件里面的内容如下

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := feizai
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES := $(LOCAL_MODULE).apk
LOCAL_MODULE_CLASS := APPS
LOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX)
LOCAL_CERTIFICATE := PRESIGNED

PRODUCT_COPY_FILES += $(LOCAL_PATH)/lib/libabenchmark.so:system/lib/libabenchmark.so
include $(BUILD_PREBUILT)

如果你apk的so文件不止一个，如下添加

PRODUCT_COPY_FILES+=
$(LOCAL_PATH)/libem_aitalk5.so:system/lib/libem_aitalk5.so
$(LOCAL_PATH)/libspeechmsc.so:system/lib/libspeechmsc.so
$(LOCAL_PATH)/libttsaisound.so:system/lib/libttsaisound.so
$(LOCAL_PATH)/libvadLib.so:system/lib/libvadLib.so

顶

0

㈤ 如何学习MTK 编译android系统的framework层源码，需要看一些什么文档，最近在公司需要学习、

mtk有个叫makeMtk的脚本文件，直接执行就行，后面参数加上自己要编译的模块，比如./makeMtk -t mm frameworks/base/core/res

㈥ 如何编译 MTK 的模拟器

MTK的emulator是基于MTK平台的codeabse编译得到用来模拟真机的虚拟Device,以下是具体的操作步骤：
1. Build MTK SDK Packages
-对于mt6572以前的chip，用如下的命令编译:
./makeMtk banyan_addon
-从mt6572开始的chip,由于mt6572之后CPU开始支持X86架构，其performace会更好，mt6572之后，建议编译x86的emulator来使用.

./makeMtk banyan_addon_x86

编译完成后会在out/host/linux-x86/sdk_addon下生成MTK的SDK包，比如mtk_sdk_api_addon-17.1.zip，(其中17是android api level)

2. 解压mtk_sdk_api_addon_17.1.zip
将解压后的mtk_sdk_api_addon-17.1整个文件夹放在android原本的sdk的add-ons目录下。

3. 拷贝emulator相关的执行文件到android sdk tool下：
- 对ICS 4.0之前的版本：
进 入android-sdk-windows\add-ons\banyan_addon_ALPS.GB.FDD.MP.V1_eng\tools 目录下，将其中的 emulator.exe 或者 emulator（如果使用Linux的SDK的话）复制出来，覆盖android-sdk-windows\tools下的相应 emulator.exe

- 对ICS 4.0及之后的版本：
将 mtk_sdk_api_addon-15.1\emulator对应文件夹下的emulator,emulator-arm,emulator-x86 这三支文件替换android原本sdk的tools目录下的emulator,emulator-arm,emulator-x86这三支文件(建议备 份google原始sdk下的emulator,emulator-arm,emulator-x86，以便后面用到Google emulator)。

4. 创建新的AVD
在Target里面选择带有MediaTek标志的，然后启动这一AVD就可以了
PS：创建AVD时需要同步将SDK的版本升级到相对的android版本，比如JB2对应的android API level 17,则对应SDK的版本也要升级到level 17,否则将在创建AVD的时候将load不出带MediaTek标志的target

㈦ android 怎么编译otapackage

在make android系统后，会生成系统的img文件。 make otapackage 会生成sd卡用的全部系统升级包,有260M多。要生成增量升级包。需要按以下步骤。 mkdir ~ /OTA source build/envsetup.sh; choosecom 1 1 7 eng make;make otapackage

㈧ Yocto编译杰发或MTK的linux或android时的几个问题

编译问题1（audiomanager_7.0.bb的do_configure报错）：

错误：CMake Error at Plugins/PluginCommandInterfaceCAPI/cmake/CommonAPI.cmake:352 (message):

|   Failed to generate files from FIDL:

手动执行一下：

$ commonapi-generator-linux-x86 -ll verbose -sk Default -d . /data/linux/hz_rs28_bm/sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/audiomanager/7.0-r1/audiomanager-7.0/Plugins/PluginCommandInterfaceCAPI/fidl/CommandInterface.fidl

-bash: /data/linux/hz_rs28_bm/sources/src/build/tools/commonapi_tool/commonapi-generator/commonapi-generator-linux-x86: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

解决（需要安装32位的glibc库和32位java jre环境）：

$ sudo yum install glibc.i686

$ sudo yum install java-1.8.0-openjdk.i686

$ sudo ln -s /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-1.el7_6.i386/jre/bin/java /bin/java

$ java -version    （保证是32位的java）

编译问题2（perl_5.20.0.bb的do_package报错）：

错误：ERROR: obj failed with exit code 256 (cmd was ‘arm-poky-linux-gnueabi-obj’ –only-keep-debug

… generate_uudmap: File format not recognized

解决（tar在1.29版本之后需要exclude在路径的前面）：

sources/meta/poky/bitbake/lib/bb/fetch2/bzr.py

tar_flags = “–exclude ‘.bzr’ –exclude ‘.bzrtags'”

修改成：

tar_flags = “–exclude=’.bzr’ –exclude=’.bzrtags'”

sources/meta/poky/bitbake/lib/bb/fetch2/cvs.py

tar_flags = “–exclude ‘CVS'”

修改成：

tar_flags = “–exclude=’CVS'”

sources/meta/poky/bitbake/lib/bb/fetch2/repo.py

tar_flags = “–exclude ‘.repo’ –exclude ‘.git'”

修改成：

tar_flags = “–exclude=’.repo’ –exclude=’.git'”

sources/meta/poky/bitbake/lib/bb/fetch2/svn.py

tar_flags = “–exclude ‘.svn'”

修改成：

tar_flags = “–exclude=’.svn'”

sources/meta/poky/meta/recipes-devtools/quilt/quilt-0.63.inc

       tar -cf – bin/ –exclude \*.in | ( cd ${D}${PTEST_PATH} && tar -xf – )

       tar -cf – compat/ –exclude \*.in | ( cd ${D}${PTEST_PATH} && tar -xf – )

       tar -cf – quilt/ –exclude \*.in | ( cd ${D}${PTEST_PATH} && tar -xf – )

       tar -cf – test/ –exclude mail.test –exclude delete.test | ( cd ${D}${PTEST_PATH} && tar -xf – )

修改成：

        tar -c –exclude=\*.in bin/ | ( cd ${D}${PTEST_PATH} && tar -xf – )

        tar -c –exclude=\*.in compat/ | ( cd ${D}${PTEST_PATH} && tar -xf – )

        tar -c –exclude=\*.in quilt/ | ( cd ${D}${PTEST_PATH} && tar -xf – )

        tar -c –exclude=mail.test –exclude=delete.test test/ | ( cd ${D}${PTEST_PATH} && tar -xf – && chmod 777 test)

sources/meta/poky/meta/recipes-extended/sed/sed-4.2.2/sed-add-ptest.patch

+       cd $(BUILDDIR); tar -cf – $(TESTDIR) –exclude *.o | ( cd $(DESTDIR) && tar -xf – )

修改成：

+       cd $(BUILDDIR); tar -c –exclude=*.o $(TESTDIR) | ( cd $(DESTDIR) && tar -xf – )

sources/meta/poky/meta/recipes-support/attr/acl.inc

tar -cf – test/ –exclude nfs | ( cd ${D}${PTEST_PATH} && tar -xf – )

修改成：

tar -c –exclude=nfs test/ | ( cd ${D}${PTEST_PATH} && tar -xf – )

sources/meta/poky/meta/recipes-support/attr/attr.inc

tar -cf – test/ –exclude ext | ( cd ${D}${PTEST_PATH} && tar -xf – )

修改成：

tar -c –exclude=ext test/ | ( cd ${D}${PTEST_PATH} && tar -xf – )

sources/meta/poky/meta/recipes-devtools/perl/perl-ptest.inc

       tar -cf – * –exclude \*.o –exclude libperl.so –exclude Makefile –exclude makefile –exclude hostperl \

               –exclude miniperl –exclude generate_uudmap –exclude patches | ( cd ${D}${PTEST_PATH} && tar -xf – )

修改成：

        tar -c –exclude=\*.o –exclude=libperl.so –exclude=Makefile –exclude=makefile –exclude=hostperl \

                –exclude=miniperl –exclude=generate_uudmap –exclude=patches * | ( cd ${D}${PTEST_PATH} && tar -x )

编译问题3（libunwind_1.1.bb的do_compile报错）：

错误：make[1]: latex2man: Command not found

解决：

$ sudo yum install texlive-tetex

$ sudo rpm -ivh ~/latex2man-1.18-2.noarch.rpm

编译问题3（qt5-app_1.0.bb的do_compile报错）：

错误（有一批类似的错误）：ld: cannot find -lgtest

解决：

$ vi atc_linux/application/btate/btate.pro

equals(MY_BUILD_SYSTEM, atc) {

    LIBS += -L $(DA_LIBDIR)/lib -lgtest -lpthread -lbluetoothclient -lglobalbus -lappobj -lapputils

} else {

    LIBS += -L$(DA_TOP)/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/atc-binarys/1.0-r0/image/usr/lib -lgtest -lpthread -lbluetoothclient -l

globalbus -lappobj -lapputils

}

$ vi atc_linux/application/gps/gps_bin.pro

equals(MY_BUILD_SYSTEM, atc) {

    LIBS += -L $(DA_LIBDIR)/lib  -lapputils  -lglobalbus -lappobj -lgps

} else {

    LIBS += -L$(DA_TOP)/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gpsd/3.10-r0/gpsd-3.10/ -lapputils  -lglobalbus -lappobj -lgps

}

$ vi atc_linux/application/dvr/dvr_bin.pro

equals(MY_BUILD_SYSTEM, atc) {

        LIBS    += -L${DA_TOP}/lib/lib/ -ldvr -ludev -lsurface_atc -lglobalbus -lappobj -lapputils -lstorage_atc -lgps

} else {

        LIBS    += -L${DA_TOP}/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gpsd/3.10-r0/gpsd-3.10/ -ldvr -ludev -lsurface_atc -lglobalbus –

lappobj -lapputils -lstorage_atc -lgps

}

$ vi atc_linux/application/dvr/dvr_bin.pro

INCLUDEPATH +=  ${DA_TOP}/kernel/kernel-3.18/drivers/ \

                ../common/  \

                ../utils/   \

                ../appobj/include/          \

                ../globalbus/include/       \

                ../appcommon/include/       \

                ../storage_atc/             \

                ../dvr/gps/             \

                ../gps/include/         \

                ../gps/includeex/       \

编译问题4（makall报错）：

报错：./makall: line 169: mkisofs: command not found

解决：$ sudo yum install mkisofs

编译问题5（修改ac83xx_systemd_defconfig再编译时报错）：

报错：Applying patch remove-selinux-android.patch

patching file system/extras/ext4_utils/make_ext4fs.c

Hunk #1 FAILED at 62.

1 out of 1 hunk FAILED — rejects in file system/extras/ext4_utils/make_ext4fs.c

解决：

$ vi sources/meta/meta-atc/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb

在里面做个假的do_patch()，bitbake会优先使用本bb文件的do_patch()函数。

do_patch(){

}

编译问题6（修改ac83xx_systemd_defconfig再编译时报错）：

报错：sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/qtbase/5.5.0+gitAUTOINC+c619d2daac-r0/git/src/corelib/tools/qregexp.cpp:3947:1: internal compiler error: in add_stores, at var-tracking.c:6000

解决：

$ cd sources/meta/poky/meta/recipes-devtools/gcc/gcc-4.9/

$ wget  http://openlinux.windriver.com/overc/sources/core2_64/gcc-4.9.2-r0.1/0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch

$ vi sources/meta/poky/meta/recipes-devtools/gcc/gcc-4.9.inc

    file://0058-gcc-r212171.patch \

    file://0059-gcc-PR-rtl-optimization-63348.patch \

    file://target-gcc-includedir.patch \

    file://0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch \

其实就是这个文件：

$ cat 0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch

From Mon Sep 17 00:00:00 2001

From: =?UTF-8?q?Stefan=20M=C3=BCller-Klieser?= <[email protected]>

Date: Tue, 7 Apr 2015 16:15:11 +0200

Subject: [PATCH] gcc/var-tracking.c: backport from gcc trunk r212178

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

resolves a bug seen on cortexa8 building qt5 libraries.

2014-06-30  Joseph Myers  <[email protected]>

    * var-tracking.c (add_stores): Return instead of asserting if old

    and new values for conditional store are the same.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@212178 138bc75d-0d04-0410-961f-82ee72b054a4

Signed-off-by: Stefan Müller-Klieser <[email protected]>

---

gcc/var-tracking.c | 3 ++-

1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c

index 65d8285..7c38910 100644

--- a/gcc/var-tracking.c

+++ b/gcc/var-tracking.c

@@ -5997,7 +5997,8 @@ add_stores (rtx loc, const_rtx expr, void *cuip)

    {

      cselib_val *oval = cselib_lookup (oloc, GET_MODE (oloc), 0, VOIDmode);

-      gcc_assert (oval != v);

+      if (oval == v)

+        return;

      gcc_assert (REG_P (oloc) || MEM_P (oloc));

      if (oval && !cselib_preserved_value_p (oval))

--

1.9.1

编译问题7（修改ac83xx_systemd_defconfig再编译时报错）：

报错：libevdev/1.2.2-r0/libevdev-1.2.2/test/test-main.c:24:19: fatal error: check.h: No such file or directory

解决：

$ vi meta/poky/meta/recipes-support/libevdev/libevdev_1.2.2.bb

LIC_FILES_CHKSUM = “file://COPYING;md5= \

                    file://libevdev/libevdev.h;endline=21;md5=″

DEPENDS += “libcheck”

SRC_URI = “ http://www.freedesktop.org/software/libevdev/ ${BP}.tar.xz”

编译问题8（修改ac83xx_systemd_defconfig再编译时报错）：

报错：python报错： ‘do_rootfs’, lineno: 17, function

Exception: CalledProcessError: Command ‘[‘’, ‘-ks’, …

解决： 没有实际问题，重新编译一次即可，可能是机器太忙导致超时，或者某个命令执行不成功。

编译问题9（preuboot编译工具问题）：

报错：make: armv7a-mediatek451_001_vfp-linux-gnueabi-gcc: Command not found

解决：

$ vi atc_linux/bootloader/preuboot/Makefile

#CROSS_COMPILE  :=armv7a-mediatek451_001_vfp-linux-gnueabi-

CROSS_COMPILE  :=arm-poky-linux-gnueabi-

$ vi ../../atc_linux/bootloader/preuboot/driver/mmc/include/linux/list.h

#ifndef NULL

    #define NULL 0

#endif

㈨ 如何编译一个可以烧写进手机中的ROM，Android安卓开发者

首先．还是跟其它文章讲的一样．先下载ANDORID的源码．在下源码之前．请看下面第一步
----------
增加代码，下真机配置

1
vim .repo/local_manifest.xml

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<project path="kernel" name="kernel/msm" revision="refs/heads/android-msm-2.6.29"/>
<project path="hardware/htc/dream" name="platform/hardware/htc/dream" revision="master"/>

</manifest>

增加上面这段代码，为一个配置．告诉服务器．我们下的代码．是要装进真机的．
（就为了多下载一个KERNEL下来。。还有下载DREAM的真机配置参数..）

小哈在这里折腾了很久．很久．．非常久．．回忆起来内牛满面

-----
下相关的代码

2.

repo sync

-----
3.
vim env_rc
加入:
export EMU=/home/coconut/cupcake/out/host/linux-x86/bin
export ARCH=arm
export CROSS_COMPILE=arm-eabi-
export PATH=$PATH:/home/coconut/cupcake/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin:${EMU}

source env_rc

4.

编译内核及无线网络驱动

$ cd $ANDROID/kernel
$ make ARCH=arm CROSS_COMPILE=../prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- msm_defconfig # 设定默认的msm配置

#编译内核
make ARCH=arm CROSS_COMPILE=../prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-

#编译无线网络驱动
cd $ANDROID/system/wlan/ti/sta_dk_4_0_4_32
make ARCH=arm CROSS_COMPILE=$ANDROID/prebuilt/linux-86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- KERNEL_DIR=$ANDROID/kernel

//内核拷到目录下
$ cp $ANDROID/kernel/arch/arm/boot/zImage $ANDROID/vendor/htc/dream-open/kernel
$ cp $ANDROID/system/wlan/ti/sta_dk_4_0_4_32/wlan.ko $ANDROID/vendor/htc/dream-open/wlan.ko

5.
在HTC网站(developer.htc.com/adp.html)
下载名为signed-dream_devphone_userdebug-ota-14721.zip的包，并把它放在$ANDROID目录下
$ cd $ANDROID
$ source build/envsetup.sh

$ lunch aosp_dream_us-eng # 指明机型
这样编译出来.就会在OUT下出来一个DREAM_OPEN的目录.里面就有相关的镜像文件了.

$ cd vendor/htc/dream-open
$ ./unzip-files.sh ＃ 解压htc相关驱动
$ cd $ANDROID
$ vi buildspec.mk ＃ 新建配置文件

－－－－
Vim htc_dream.mk

vim /oracle/android/src/vendor/htc/dream-open/htc_dream.mk

在头部增加
PRODUCT_PACKAGES := \
Calculator \
Email \
ImProvider \
SdkSetup \
VoiceDialer

完成。
回到根目录

cd /oracle/android/src
vim buildspec.mk
加入( 2010.7.7 不需要加入)：
#TARGET_PRODUCT:=htc_dream
#TARGET_PREBUILT_KERNEL:=kernel/arch/arm/boot/zImage

增加:
CUSTOM_LOCALES:=zh_CN

然后：

其中增加环境：
ubuntu 8.10 , sudo apt-get libelf-dev

make clean

// 保证PC有 1280 内存, 加上 1000 SWAP空间..虚拟机也是如此.
然后开始编译 BOOT.IMG SYSTEM.IMG USERDATA.IMG:
make -j2

接下来
mmm -B $ANDROID/packages/apps/Luancher/ snod

cd out/target/proct/dream-open/

//先测试:
emulator -system . -kernel ~/cupcake/prebuilt/android-arm/kernel/kernel-qemu -data userdata.img
因为出来了BOOT.IMG.这个是真机的..所以不能用BOOT做为内核.要用模拟器来做内核.

//然后开始烧机
fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash userdata userdata.img

fastboot reboot

㈩ MTK6582编译Android手机程序

13年11月谷歌低调发布安卓4.4，之前人们一直在猜疑，到底MTK(联发科）会不会为MT6589,MT6582这些CPU提供升级至安卓4.4解决方案呢？争论不断，后发现联想VIBE官方论坛发出一份升级计划，其中包含了MTK可以升级至安卓4.4,升级机型含括了MTK6589、MT6582和MT6592，因此可以基本确认，此类CPU都将可能升级至安卓4.4。 安卓4.4介绍 1、新特性编辑支持两种编译模式 除了默认的 Dalvik 模式,还支持 ART 模式 2、RAM优化 Android 4.4 KitKat针对RAM占用进行了优化，甚至可以在一些仅有512MB RAM的老款手机上流畅运行。它也进一步优化了系统在低配硬件上的运行效果， 支持内核同页合并 KSM,ZRAM 交换，似乎是为了更好地在众多智能穿戴设备上运行。 3、新图标、锁屏、启动动画和配色方案 之前蓝绿色的配色设计被更换成了白/灰色，更加简约，另外图标风格也进一步扁平化，还内置了一些新的动画，整体来说界面更漂亮、占用资源更少。另外，还加入了半透明的界面样式，以确保状态栏和导航栏在应用中发挥更好的效果。 4、新的拨号和智能来电显示 首先，新的拨号程序会根据使用习惯，自动智能推荐常用的联系人，方便快速拨号；同时，一些知名企业或是服务号码的来电，会使用谷歌的在线数据库进行匹配自动显示名称，即使手机中没有存储。 5、加强主动式语音功能 在Nexus 5上，可以通过说“OK，Google”来启动语音功能，而不需要触碰任何按键或是平煤，但并非支持所有机型。另外，语音搜索功能的精度也提升了25%，更加准确，还支持买电影票等新功能。 6、集成Hangouts IM软件 Android 4.4内置了Hangouts IM软件，类似于国内的微信，可以实现跨平台的文字、语音聊天功能，也能够传输图片、视频等各种文件。 7、全屏模式 不论是在看电子书、或是使用任何应用程序，都能够方便地进入到全屏模式，隐藏虚拟按键，带来更投入的使用体验。只需滑动屏幕边缘，便可找回按键，也十分方便。 8、支持Emoji键盘 终于，Android也能够支持丰富有趣的Emoji输入了，可以让邮件或是信息更加个性化。 9、轻松访问在线存储 可以直接在手机或平板电脑中打开存储在Google Drive或是其他云端存储的文件，支持相册或是QuickOffice等软件，十分方便。 10、无线打印 可以使用谷歌Cloud Print无线打印手机内的照片、文档或网页，其他打印机厂商也将迅速跟进，发布相关应用。 11、屏幕录像功能 Android 4.4增加了屏幕录像功能，可以将所有在设备上的操作录制为一段MP4视频，并选择长宽比或是比特率，甚至是添加水印。 12、内置字幕管理功能 在播放视频时可自行添加字幕。 13、计步器应用 Android 4.4内置了计步器等健身应用，谷歌也在加紧与芯片制造商的合作，为未来的智能手表做准备。 14、低功耗音频和定位模式 Android 4.4加入了低功耗音频和定位模式，进一步减少设备的功耗。 15、新的接触式支付系统 虽然谷歌钱包还没正式推出，但是Android 4.4中已经加入了新的接触式支付功能，通过NFC和智能卡，可以在手机端轻松完成支付。 16、新的蓝牙配置文件和红外兼容性 Android 4.4内置了两个新的蓝牙配置文件，可以支持更多的设备，功耗也更低，包括鼠标、键盘和手柄，还能够与车载蓝牙交换地图。另外，新的红外线遥控接口可以支持更多设备，包括电视、开关等等。