【转】Android 将本身的应用改成系统应用

所谓系统程序就是system/app目录中的程序，普通应用转换成系统程序后有稳定、减小内存（DATA）空间占用、恢复出厂设置后不会消失、修改系统时间、调用隐藏方法、系统关机重启、静默安装升级卸载应用等等等等优势，想知道怎么操做？接下来咱们介绍三种方法。

第一种：使用ADB命令将app安装在system/app目录下

参考：android 将本身的应用改成系统应用

这种方法的原理就是：

一、把apk文件移动到system/app目录，
二、.so文件移动到system/lib目录。
三、修改相应的权限

操做步骤：

1. 将你的手机数据线，插上，把你的设备设置为容许usb调试
2. 打开命令终端cmd
3. 输入命令 adb shell
4. 肯定能进入系统

5. 输入命令 mount

6. 由于system默认是只读文件夹，因此根据上面的提示输入下面命令，使其变为可读写
mount -o remount /dev/block/nandd /system （图）

再出输入 mount 查看system和上面的不同了，说明正确

7. 输入 exit 退出android系统终端

8. 解压你的apk文件，进入查看lib/armeabi文件夹下有没有 .so文件，若是没有这种库文件的话，直接跳到第10步，（由于有些apk文件是要调用动态连接库的，你不拷贝的话，就没有办法运行！会报错）若是有的话， 将这些*.so文件都拷贝到/system/lib文件夹下：

命令：adb push libiReader_txtparser.so system/lib

九、拷贝完了以后呢，要给这些库文件添加权限，看看别的库文件权限是几

chmod 644 xxxxx.so

• 1

• 1

10. 将你的apk文件拷贝进入/system/app（该文件夹里存放着因此系统级别的apk），图中我是将iReader.apk拷贝过去的

11. 再次进入android终端 adb shell
12. 进入system/app文件夹 cd system/app
13. 查看其余apk的权限 ll 能看出区别

14. 修改iReader.apk权限使其和其余的同样 chmod 644 iReader.apk

15. 搞定这些以后，重启设备 reboot
16. 看看系统里面是否是安装好了该应用，点击一下，看是否正常运行，能够的话，再检测是否没法卸载！

第二种：借助工具把app转为系统应用（原理和方法一同样）

转载：安卓进阶教程：怎样把应用转换成系统程序

RE管理器转换和LINK2SD均可以实现，任选其一便可

使用RE管理器转换

一、首先咱们把须要转换的程序在电脑上用压缩软件打开 ，看有没有lib这个目录。若是有，再把lib目录打开，直到出现以.so结尾的文件，把文件都拖出来备用。

二、把须要转换的应用（apk文件）连同刚拖出的.so文件（若是有），放到手机内存卡，
三、用RE管理器复制到system目录，把权限更改如图，
四、把更改权限后的apk文件移动到system/app目录，.so文件移动到system/lib目录。
五、完成后重启手机，应用就转换成系统程序了。

使用LINK2SD转换

若是感受以上方法麻烦，也可借助工具来操做，LINK2SD、钛备份等软件均可以把普通程序转换为系统程序，以LINK2SD为例，打开LINK2SD，找到须要软件的程序，点击，再点操做，选择转换系统应用，接着会有个确认窗口，确认后，重启手机程序就转换好了。

第三种：使用signapk打包成系统应用

参考：
android之使用signapk打包成系统应用，获取系统权限
使用platform密钥来给apk文件签名的命令
Android安全开发之通用签名风险
关于android:sharedUserId=”android.uid.system”这个系统级权限
安装APK 时, 提示” 共享用户权限不完整” , 不能安装成功, 如何解决?
https://github.com/android/platform_build/tree/master/target/product/security

为了更好地理解下面介绍的两种方法的原理，先来学习几个概念：

Android应用签名机制

Android系统要求安装的应用必须用数字证书进行签名后才能安装，而且签名证书的私钥由应用开发者保存。签名证书的生成也由开发者本身生成。在应用安装时会校验包名（package name）和签名，若是系统中已经存在了一个相同的包名和签名的应用，将会用新安装的应用替换旧的；若是包名相同可是签名不一样，则会安装失败。

为何须要数字签名？

数字签名是防止要保护的内容被篡改，用非对称加密算法。先对要保护的内容进行消息摘要，用私钥对消息摘要进行加密，生成数字签名，将数字签名和要保护的内容一块儿分发出去。 内容接收者用公钥对数字签名解密获得发送者给的消息摘要A，内容接收者对接收到的内容进行用相同的消息摘要算法处理获得消息摘要B，对比A和B是否相同，来断定传送的内容是否被篡改。 正常的APK文件是个ZIP压缩文件，除了应用的可执行文件、资源文件，还包括这些可执行文件、资源文件的摘要信息，数字证书的公钥信息等。而且经过这些签名信息能够肯定APP和其开发者的关系。

进行签名须要的工具备哪些？

对apk进行签名须要用到签名证书和签名工具。Android系统要求对APP进行签名的数字证书能够由开发者本身生成。签名工具备jarsigner和signapk。jarsigner是Java自己自带的一个工具，他也能够对jar进行签名的；而signapk是专门为了Android应用程序apk进行签名的工具。两者的区别是：jarsigner工具签名时使用的是keystore签名文件，signapk工具签名时使用的是pk8，x509.pem文件。

签名后的文件都有哪些？

应用签名完后在应用的META-INF目录下会有三个文件：

CERT.RSA、CERT.SF和MANIFEST.MF。

MANIFEST.MF中保存了全部其余文件的SHA1摘要并base64编码后的值。

CERT.SF文件 是对MANIFEST.MF文件中的每项中的每行加上“rn”后，再次SHA1摘要并base64编码后的值（这是为了防止经过篡改文件和其在MANIFEST.MF中对应的SHA1摘要值来篡改APK，要对MANIFEST的内容再进行一次数字摘要）。

CERT.RSA 文件：包含了签名证书的公钥信息和发布机构信息。

对安装包的校验过程在源码的frameworks/base/core/java/android/content/pm/PackageParser.java类中能够看到

什么是通用签名？

搭建好Android开发环境后（使用Eclipse或Android Studio），对APK签名的默认密钥存在debug.keystore文件中。在linux和Mac上debug.keystore文件位置是在~/.android路径下，在windows目录下文件位置是C:\user\用户名.android路径下。

除了debug.keystore外，在AOSP发布的Android源码中，还有如下几个证书是公开的，任何人均可以获取，在源码的build/target/product/security目录中：

这几个证书的做用：

testkey

Generic default key for packages that do not otherwise specify a key.

platform

Test key for packages that are part of the core platform.

shared

Test key for things that are shared in the home/contacts process.

media

Test key for packages that are part of the media/download system.

verity

Test Key for verifiedboot system imagein Android Lollipop. Sign boot.img,sign verity metadata in system.img.

通用签名风险：

（1）若是攻击者的应用包名与目标应用相同，又使用了相同的密钥对应用进行签名，攻击者的应用就能够替换掉目标应用；

（2）另外目标应用的自定义权限android:protectionlevel为“signature”或者“signatureOrSystem”时，保护就形同虚设；

（3）若是设备使用的是第三方ROM，而第三方ROM的系统也是用AOSP默认的签名，那么使用若是使用系统级签名文件签名过的应用，权限就获得了提高。

具体的实现方法：

第一种是须要在Android系统源码的环境下用make来编译：

1. 在应用程序的AndroidManifest.xml中的manifest节点中加入android:sharedUserId=”android.uid.system”这个属性。
2. 修改Android.mk文件，加入LOCAL_CERTIFICATE := platform这一行
3. 使用mm命令来编译，生成的apk就有修改系统时间的权限了。

第二种：

下面着重介绍一个这个方法：

1. 加入android:sharedUserId=”android.uid.system”这个属性。

<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.jant.addview" android:sharedUserId="android.uid.system" > <application  ...（省略若干代码） </application> </manifest>

2. 使用本身的签名文件，生成apk

3. 使用通用签名来从新给apk文件签名。

3.1 .准备好platform.pk八、platform.x509.pem和签名工具signapk.jar（3个文件的下载地址），还有本身的apk，放在同一个文件夹下。

3.2 在cmd下进入到该文件夹后，使用以下命令：

3.3 回车后咱们的文件夹下已经多了一个new.apk文件了，这就将咱们的应用打包成系统应用

---

你也能够在github中去下载，可是下载的是SignApk.java，须要进行一些处理，以下

1.1.进入\build\target\product\security,找到【platform.pk8】和【platform.x509.pem】系统密钥。
1.2.进入\build\tools\signapk找到SignApk.java，运行 javac编译成SignApk.class
1.3.执行命令java com.android.signapk.SignApk platform.x509.pem platform.pk8 input.apk output.apk

最后解释一下原理

首先加入android:sharedUserId=”android.uid.system”这个属性。经过Shared User id,拥有同一个User id的多个APK能够配置成运行在同一个进程中。那么把程序的UID配成android.uid.system，也就是要让程序运行在系统进程中，也就是系统应用。

只是加入UID还不够，若是这时候安装APK的话发现没法安装，提示签名不符，缘由是程序想要运行在系统进程中还要有目标系统的platform key，就是上面第二个方法提到的platform.pk8和platform.x509.pem两个文件。用这两个key签名后apk才真正能够放入系统进程中。第一个方法中加入LOCAL_CERTIFICATE := platform其实就是用这两个key来签名。

这也有一个问题，就是这样生成的程序只有在原始的Android系统或者是本身编译的系统中才能够用，由于这样的系统才能够拿到platform.pk8和platform.x509.pem两个文件。要是别家公司作的Android上连安装都安装不了。试试原始的Android中的key来签名，程序在模拟器上运行OK，不过放到小米四上安装uibl，以下图，这样也是保护了系统的安全。

最后还说下，这个android:sharedUserId属性不仅能够把apk放到系统进程中，也能够配置多个APK运行在一个进程中，这样能够共享数据，应该会颇有用的。
你在Manifest.xml里声明使用了shareuserid 或者一些特殊permission，好比你shareuserid到uid.system，就必须使用系统platform签名来签你的apk，不然是不能安装的，同理share到其余用户id或者其余process上也是得用跟那个process运行的apk同样的签名
通常签名确定是厂商私有的，你确定是没办法了，除非机器烧的是开发版本(eng)

检验app是否已是系统应用

查看应用的进程属性，若是是system用户组，说明已是系统应用。

 

 

from：https://blog.csdn.net/m0_37135879/article/details/81134472?tdsourcetag=s_pcqq_aiomsg