关于MTK平台第三方APK的定制方法

MTK平台Android项目APK预置方案

 

项目开发中，通常需要向系统中预置一些APK，这里简单介绍一下MTK平台预置APK的方法。

 

需要预置的apk可以放置在目录：vendor/mediate/${Project}/artifacts/out/target/product/${Project}下，

大致可以分成两种情况：

1.      用户不可卸载的：例如中兴提供的一些APK

相应的apk直接放在目录：system/app下即可。

注：需要将apk中的动态库手动提取出来，并置于system/lib下面。

 

2.      用户可以卸载：

相应的apk直接放在该目录下：data/app，这样用户就可以手动进行卸载了。

 

还有一种情况，当用户卸载该APK后，恢复出厂设置还可以还原出来：

MTK平台已经支持该特性，具体操作方法如下：

 

需要版本在ALPS.GB.TDFD.MP.V1.7和ALPS.GB.FDD2.MP.V4.7之后，如果低于此版本，可向MTK申请patch：ALPS00092543。

²  在mediatek/config/${Project}/ProjectConfig.mk中修改：

MTK_SPECIAL_FACTORY_RESE=yes

²  在system下新建目录appbackup，将需要恢复的apk拷贝到这个目录。

²  在data/app目录下创建一个隐藏的空文件，命名为.keep_list

²  在system/app目录下创建一个隐藏文件，命名为.restore_list，并写入类似的语句：

/system/appbackup/XXX.apk，即需要恢复的apk的路径。

 

这样，当卸载了/data/app下的apk之后，再恢复出厂设置，系统会从.restore_list文件中读取apk的名字，然后从/system/appbackup目录下把相应的apk重新拷贝的/data/app下，从而恢复用户已经卸载的apk。

注：需要将apk中的动态库手动提取出来，并置于system/lib下面。

 

对于以上方法，MTK都有详细的文档说明，可以按照相关文档进行操作。

 

 

WIND第三方APK预置方案

基于软件版本的管理问题（通常项目过程中，会先后进入入库阶段和量产阶段，这两个阶段的APK通常不是完全相同的）。因此，在代码中，我们分非量产和量产两个目录来管理所有的APK信息，二者分别对应非量产版本和量产版本，并且在ProjectConfig.mk中添加了一个量产宏MTK_ENABLE_MASS_SUPPORT来控这些APK的拷贝：

从上面的描述中，我们可以得出APK的预制方法：

1.        中移适配的APK资源，分别放在mass和unmass目录下；相关的so库分别放在对应的system/lib下

2.        中兴提供的入库合入的APK资源，分别放在mass和unmass目录之下；相关的so库分别放在对应的system/lib下

3.        中兴提供的量产阶段的APK资源，放在mass目录下；相关的so库分别放在对应的system/lib下即可

 

 

重要参考：apk里的so库如何摆放

 

在android APK的根目录有一个libs文件夹，此文件夹下包含了armeabi 和armeabi-v7a两个文件夹，我们的c代码编译成的本地库（各种.so）就会放在这两个文件夹其中的一个。

那armeabi-v7a 与armeabi有什么区别，该将so库放哪个文件夹？

 

armeabi和armeabi-v7a是表示cpu的类型，我们知道一般的手机或平板都是用arm的cpu，不同的cpu的特性不一样：

armeabi就是针对普通的或旧的armcpu

armeabi-v7a是针对有浮点运算或高级扩展功能的arm cpu

这两个目录都可以放，具体要看开发的apk的定位，如果想将apk发布到网络上供不同的机器使用，那么建议用armeabi（兼容性好），如果只是自己平台上用，则可以用armeabi-v7a