【转】Android 将自己的应用改为系统应用

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

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

参考：android 将自己的应用改为系统应用

这种方法的原理就是：

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

操作步骤：

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

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

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管理器转换

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

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

使用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.pk8、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