㈠ 求问android怎么在代码里获得系统文件的读写权限
本来以为就没有办法在应用程序这一层改系统时间了，后来在网上搜了好久，知道这个目的还是可以达到的。
第一个方法简单点，不过需要在Android系统源码的环境下用make来编译：
1. 在应用程序的AndroidManifest.xml中的manifest节点中加入
android:sharedUserId="android.uid.system"这个属性。
2. 修改Android.mk文件，加入LOCAL_CERTIFICATE := platform这一行
3. 使用mm命令来编译，生成的apk就有修改系统时间的权限了。
第二个办法麻烦点，不过不用开虚拟机跑到源码环境下用make来编译：
1. 同上，加入android:sharedUserId="android.uid.system"这个属性。
2. 使用eclipse编译出apk文件，但是这个apk文件是不能用的。
3. 用压缩软件打开apk文件，删掉META-INF目录下的CERT.SF和CERT.RSA两个文件。
4. 使用目标系统的platform密钥来重新给apk文件签名。这步比较麻烦，
首先找到密钥文件，在我的Android源码目录中的位置
是"build argetproctsecurity"，下面的platform.pk8和platform.x509.pem
两个文件。
然后用Android提供的Signapk工具来签名，signapk的源代码是
在"build oolssignapk"下，
用法为"signapk platform.x509.pem platform.pk8 input.apk output.apk"，
文件名最好使用绝对路径防止找不到，也可以修改源代码直接使用。
这样最后得到的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，不过放到G3上安装直接提示"Package ... has no signatures that match those in shared user android.uid.system"，这样也是保护了系统的安全。
java代码 1、必须是Android系统开发人员，否则你无法修改init.rc等文件。 2、你的应用程序必须要获得system权限。 在应用层 你要想用代码获得系统文件权限，除非你手机root了 要么你自己坐rom。。。。 自己修改 init，rc
方法/步骤
1
首先找到你要操作的文件夹，这里用一个声卡相关的文件夹做例子。选中文件夹。右击它。选择文件的属性，安全--->高级。
2
更改所有者，如图所示。在输入对象名称那儿，输入你的账户名称，我的是微软账户。输入完之后确定。
3
回到刚才的界面，你会看到所有者已经改变了，变成了你的账号。然后确定退出，回到文件夹。（一定要确定后退出回到文件中，才能进行下一步）
4
再次回到刚才的界面。禁止所有继承。
5
添加用户。输入账号，我输入的是微软账号。输入后确定。
通过第三方软件获得Root权限，可以访问和修改手机操作系统里几乎所有的文件，但这样操作有可能影响手机的稳定性，出现死机、重启等人为性故障。
另外获取权限后一般对存储器和CPU等主板上主要部件引起不良。Root属于修改操作系统软件，按照条例不属于包修范围。为了提升顾客满意度，对Root顾客提供免费升级固件服务，如果Root已影响到手机硬件需要更换主板，则需要收取主板费用。
若您的机器Root后需将机器恢复到原来的系统版本，请将机器送到服务中心，由售后工程师帮助检查处理。自行将设备恢复出厂设置是无法取消Root权限的。
对于已经获取所有权限的文件，建议大家还是恢复到原来的状态。今天就跟大家分享一下如何恢复系统文件的默认权限，Windows 7和Windows 8系统都是一样的操作步骤。这里以平时最常修改的hosts文件为例，下图显示已获取hosts文件所有权限。已获得所有权限的hosts文件恢复权限有点类似于于逆向操作，首先点选Administrators组（上图蓝色条），然后点击下方的“高级”按钮，切换到“所有者”标签。高级安全设置-所有者在上面的窗口中，点击“编辑”按钮打开新窗口来更改所有者。编辑所有者到这一步，你会发现可更改的所有者并没有当初替换时的TrustedInstaller，怎么办？别急，点击“其他用户或组”来添加它。在新开的窗口里，输入：NT SERVICE＼TrustedInstaller，注意前面的NT SERVICE一定要加上，否则系统不认。添加TrustedInstaller用户完成后点击确定回到上一窗口，此时会看到TrustedInstaller用户出现了，接下去就是选择它，然后一路确定退出各个窗口。文件所有权恢复到默认状态
File类里面就有canRead，canWrite，canExecute方法啊。 查看原帖>>
麻烦采纳，谢谢!
用re
先耐心的把这里的帖子看上几页，再多网络网络资料，不要手机一上手就玩这些要root权限的内容，容易出问题，到时候问题越来越多。。。建议至少2周后再做这些事情，对你会很有帮助。 查看原帖>>
对于一般文件来说，是不需要开启administrator账户的，只需要一个简单的办法就OK啦！比如说，对待下面的这种类型的文件夹。
2
我们只需要击右键，选择“管理员取得所有权”即可。
3
对于一些程序文件来说，只需要你击右键，选择“以管理员身份运行”，也是一个非常便捷的获得管理员权限的办法。
END
开启Administrator账户的方法
Windows 7系统中，administrator账户并不是默认开启的，那么就需要我们手动开启，这也不是很难的啦！对计算机图标，击右键，选择管理。
打开界面后，选择本地用户和组，单击用户，选择administrator账户即可。
3
打开，administrator账户之后，按照以下的操作来进行就行了。
4
这样，在开始登陆的界面，即可以出现administrator账户了，选择此账户即可获得管理员最高权限，不过建议一般来说此账户还是不要开启的好，如果此账户受损，再创建帐户很容易失败。还有，在第一次开启此账户时，是不需要密码的。
这个问题其实LBE已经解决了。 1.在2012隐私保护版中，每次运行时请求系统root，创建一个开机启动服务libload.so，专门用于处理lbe自身的root请求。 2.在2013免root版中，首次运行时自动获取系统root，并把破解过的su文件复制到/system/xbin/.sv ，然后给6755的权限，专门用于处理lbe自身的root请求。 上述两种方案，均为程序自带root管理，用于解决其自身root请求。 以下代码即为方案2的原理，附件中为修改过的su文件。 ******************************************* 安卓的su文件，基本原理为 1234567if (pid=DB(Allow)) then "get uid=0 root" 白名单，程序获取rootelseif (pid=DB(Disable)) Return 黑名单，返回空else View"superuser.active" 数据库无记录，“授权管理”弹出root请求窗口endif修改后的su文件 1if (pid<>"") then "get uid=0 root" 无条件，返回root********************************************** 我反编译b.apk，然后把java应用调用runtime.exec("su")的代码全部改为runtime.exec("sa")， 然后重新打包签名好。安装这个软件。 用RE文件管理器把上面附件的su改名为sa，复制到/system/xbin/sa并改权限rwsx-rsx-r。 以后使用b.apk，获取root权限没有任何提示。 su.zip大小：249.85K 已经过网络安全检测,放心下载 点击下载下载量:133
㈡ 如何用Android MTK源码生成签名文件
在linux环境中，以Android源码目录为根目录
cd build/target/proct/security/
其中的platform.pk8是制作系统签名需要的文件、
1 在这个目录下，执行
openssl pkcs8 -inform DER -nocrypt -in platform.pk8 -out platform.pem
生成临时文件platform.pem
2 接着执行以下命令，将在目录下生成platform.p12文件，它本质上应该就是一个数字证书。
openssl pkcs12 -export -in platform.x509.pem -out platform.p12 -inkey platform.pem -password pass:android -name androiddebugkey
3 然后再执行以下，
keytool -importkeystore -deststorepass android -destkeystore ./platform.jks -srckeystore ./platform.p12 -srcstoretype PKCS12 -srcstorepass android
这个名字可以改成debug.keystore. 后缀名没有关系，eclipse和AS都识别 platform.jks
出现以下信息，表示成功生成 platform.jks
4 然后在打包 apk 的时候选择platform.jks文件，就可以直接用adb命令安装apk到机器中了。
adb install xxxx
㈢ Android基础‘V1V2V3签名’
基础概念
签名：在 APK 中写入一个“指纹”。指纹写入以后，APK 中有任何修改，都会导致这个指纹无效，Android 系统在安装 APK 进行签名校验时就会不通过，从而保证了安全性。
摘要算法： 使用一段简单的看上去随机的不可逆向的固定长度的字符串来表示一个文件的唯一性。 常见的摘要算法如MD5(128个比特位)、SHA-1算法(160/192/256个比特位)。
公钥密码体制：也称非对称算法，特点是 公钥是公开的 ，私钥是保密的。常见的如：RSA。
展开讨论一下RSA：
Android中的签名方案
V1 ：基于jarsigner(JDK自带工具，使用keystore文件进行签名) 或 apksigner(Android专门提供的，使用pk8、x509.pem进行签名)。keystore和pk8/x509.pem可以相互转换。
签名原理：首先keystore文件包含一个MD5和一个SHA1摘要。 这也是很多开放平台需要我们上传的摘要数据 。
签名APK后会在META-INF文件夹下生产CERT.RSA、CERT.SF、MANIFEST.MF三个文件。
在apk中，/META-INF文件夹中保存着apk的签名信息，一般至少包含三个文件，[CERT].RSA，[CERT].SF和MANIFEIST.MF文件。这三个文件就是对apk的签名信息。
MANIFEST.MF中包含对apk中除了/META-INF文件夹外所有文件的签名值，签名方法是先SHA1()(或其他hash方法)在base64()。存储形式是：Name加[SHA1]-Digest。
[CERT].SF是对MANIFEST.MF文件整体签名以及其中各个条目的签名。一般地，如果是使用工具签名，还多包括一项。就是对MANIFEST.MF头部信息的签名，关于这一点前面源码分析中已经提到。
[CERT].RSA包含用私钥对[CERT].SF的签名以及包含公钥信息的数字证书。
是否存在签名伪造可能：
修改(含增删改)了apk中的文件，则：校验时计算出的文件的摘要值与MANIFEST.MF文件中的条目不匹配，失败。
修改apk中的文件+MANIFEST.MF,则：MANIFEST.MF修改过的条目的摘要与[CERT].SF对应的条目不匹配，失败。
修改apk中的文件+MANIFEST.MF+[CERT].SF，则：计算出的[CERT].SF签名与[CERT].RSA中记录的签名值不匹配，失败。
修改apk中的文件+MANIFEST.MF+[CERT].SF+[CERT].RSA，则：由于证书不可伪造，[CERT].RSA无法伪造。
V2 ：7.0新增的
签名后的包会被分为四部分
1. Contents of ZIP entries（from offset 0 until the start of APK Signing Block）
2. APK Signing Block
3. ZIP Central Directory
4. ZIP End of Central Directory
新应用签名方案的签名信息会被保存在区块2（APK Signing Block） 中， 而区块1（ Contents of ZIP entries ）、区块3（ ZIP Central Directory ）、区块4（ ZIP End of Central Directory ）是受保护的， 在签名后任何对区块1、3、4的修改都逃不过新的应用签名方案的检查 。
V3 ：9.0新增的
格式大体和 v2 类似，在 v2 插入的签名块（Apk Signature Block v2）中，又添加了一个新快（Attr块） 。
在这个新块中，会记录我们之前的签名信息以及新的签名信息，以 密钥转轮的方案，来做签名的替换和升级。这意味着，只要旧签名证书在手，我们就可以通过它在新的 APK 文件中，更改签名 。
v3 签名新增的新块（attr）存储了所有的签名信息，由更小的 Level 块，以 链表 的形式存储。
其中每个节点都包含用于为之前版本的应用签名的签名证书，最旧的签名证书对应根节点，系统会让每个节点中的证书为列表中下一个证书签名，从而为每个新密钥提供证据来证明它应该像旧密钥一样可信。
这个过程有点类似 CA 证书的证明过程，已安装的 App 的旧签名，确保覆盖安装的 APK 的新签名正确，将信任传递下去。
注意： 签名方式只支持升级不支持降级，如安装了V2的包，不能覆盖替换为V1的包。
参考
Android App签名(证书)校验过程源码分析
新一代开源Android渠道包生成工具Walle
Android 签名机制 v1、v2、v3
㈣ 如何将Android 源码中编译出的apk进行自己的签名
1.将应用程序源码复制进Android源码目录中(提前编译好源码)
2.使用build/envsteup.sh 配置shell -
mm TARGET_PRODUCT=proct_name
或直接./build_android.sh 也能完成编译。
3.在源码目录：out/target/proct/proctname/obj/APPS/test_cert_intermediates 下有三个文件：package.apk package.apk.unsigned package.apk.unaligned
将package.apk.unsigned复制出来，单独进行sign.
4.在Windows下进行sign: jarsigner -verbose -keystore youkey.keystore d:\package.apk.unsigned youkey
5.zipalign -v 4 d:\package.apk.unsigned d:\package.signed.apk
㈤ 如何用Android 源码生成APK签名文件
我们很多应用需要用到系统签名，可以通过生成系统签名文件，在生成apk时使用这个签名，然后可以安装到机器中，不需要放在源码里编译，重新刷系统。
先附上 50和 20机器人通用的debugkey(图已经省略)
在Linux环境中，以Android源码目录为根目录。
其中的platform.pk8是制作系统签名需要的文件。
1、在这个目录下，执行
生成临时文件platform.pem
2、接着执行以下命令，将在目录下生成platform.p12文件，它本质上应该就是一个数字证书
3、然后再执行以下命令出现以下信息，表示成功生成platform.jks
这个名字可以改成debug.keystore. 它的后缀本身是没有关系，eclipse和AS都识别 platform.jks
4、然后在打包 apk 的时候选择platform.jks文件，就可以直接用adb命令安装apk到机器中了。
xxxx表示需要安装的apk路径
5、签名的 Key store password和Key password都是android
㈥ android 系统签名
也有提到怎么单独给一个apk签名，这里补充一下android的签名权限控制机制。
android的标准签名key有：
testkey
media
latform
hared
以上的四种，可以在源码的/build/target/proct/security里面看到对应的密钥，其中shared.pk8代表私钥，shared.x509.pem公钥，一定是成对出现的。
其中testkey是作为android编译的时候默认的签名key，如果系统中的apk的android.mk中没有设置LOCAL_CERTIFICATE的值，就默认使用testkey。
而如果设置成：
LOCAL_CERTIFICATE := platform
就代表使用platform来签名，这样的话这个apk就拥有了和system相同的签名，因为系统级别的签名也是使用的platform来签名，此时使用android:sharedUserId="android.uid.system"才有用！
在/build/target/proct/security目录下有个README，里面有说怎么制作这些key以及使用问题（android4.2）：
从上面可以看出来在源码下的/development/tools目录下有个make_key的脚本，通过传入两个参数就可以生成一对签名用的key。
其中第一个为key的名字，一般都默认成android本身有的，因为很多地方都默认使用了这些名字，我们自定义的话只需要对第二个参数动手脚，定义如下：
C ---> Country Name (2 letter code) ST ---> State or Province Name (full name) L ---> Locality Name (eg, city) O ---> Organization Name (eg, company) OU ---> Organizational Unit Name (eg, section) CN ---> Common Name (eg, your name or your server’s hostname) emailAddress ---> Contact email addre
另外在使用上面的make_key脚本生成key的过程中会提示输入password，我的处理是不输入，直接enter，不要密码！后面解释，用自定义的key替换/security下面的。
可以看到android源码里面的key使用的第二个参数就是上面README里面的，是公开的，所以要release版本的系统的话，肯定要有自己的签名key才能起到一个安全控制作用。
在上面提到如果apk中的编译选项LOCAL_CERTIFICATE没有设置的话，就会使用默认的testkey作为签名key，我们可以修改成自己想要的key，按照上面的步骤制作一个releasekey，修改android配置在/build/core/config.mk中定义变量：
在主makefile文件里面：
ifeq ($(DEFAULT_SYSTEM_DEV_CERTIFICATE),build/target/proct/security/releasekey)
BUILD_VERSION_TAGS += release-key
这样的话默认的所有签名将会使用releasekey。
修改完之后就要编译了，如果上面的这些key在制作的时候输入了password就会出现如下错误：
我在网上找到了合理的解释：
其实会出现这个错误的最根本的原因是多线程的问题。在编译的时候为了加速一般都会执行make -jxxx，这样本来需要手动输入密码的时候，由于其它线程的运行，就会导致影响当前的输入终端，所以就会导致密码无法输入的情况！
再编译完成之后也可以在build.prop中查看到变量：
这样处理了之后编译出来的都是签名过的了，系统才算是release版本
我发现我这样处理之后，整个系统的算是全部按照我的要求签名了。
网上看到还有另外的签名release办法，但是应该是针对另外的版本的，借用学习一下：
make -j4 PRODUCT-proct_mol-user dist
这个怎么跟平时的编译不一样,后面多了两个参数PRODUCT-proct_mol-user 和 dist. 编译完成之后回在源码/out/dist/目录内生成个proct_mol-target_files开头的zip文件.这就是我们需要进行签名的文件系统.
我的proct_mol 是full_gotechcn,后面加“-user”代表的是最终用户版本，关于这个命名以及proct_mol等可参考http://blog.csdn.net/jscese/article/details/23931159
编译出需要签名的zip压缩包之后，就是利用/security下面的准备的key进行签名了：
./build/tools/releasetools/sign_target_files_apks -d /build/target/proct/security out/dist/full_gotechcn-target_files.zip out/dist/signed_target_files.zi
签名目标文件 输出成signed_target_files.zi
如果出现某些apk出错，可以通过在full_gotechcn-target_files.zip前面加参数"-e =" 来过滤这些apk.
然后再通过image的脚本生成imag的zip文件，这种方式不适用与我目前的工程源码，没有做过多验证！
Android签名机制可划分为两部分：（1）ROM签名机制；（2）第三方APK签名机制。
Android APK实际上是一个jar包，而jar包又是一个zip包。APK包的签名实际上使用的是jar包的签名机制：在zip中添加一个META的子目录，其中存放签名信息；而签名方法是为zip包中的每个文件计算其HASH值，得到签名文件(*.sf)，然后对签名文件(.sf)进行签名并把签名保存在签名块文件(*.dsa)中。
在编译Android源码生成ROM的过程中，会使用build/target/proct/security目录中的4个key（media, platform, shared, testkey）来对apk进行签名。其中，*.pk8是二进制形式（DER）的私钥，*.x509.pem是对应的X509公钥证书（BASE64编码）。build/target/proct/security目录中的这几个默认key是没有密码保护的，只能用于debug版本的ROM。
要生成Release版本的ROM，可先生成TargetFiles，再使用带密码的key对TargetFiles重新签名，最后由重签名的TargetFiles来生成最终的ROM。
可以使用Android源码树中自带的工具“development/tools/make_key”来生成带密码的RSA公私钥对（实际上是通过openssl来生成的）: $ development/tools/make_key media ‘/C=CN/ST=Sichuan/L=Cheng/O=MyOrg/OU=MyDepartment/CN=MyName’ 上面的命令将生成一个二进制形式（DER）的私钥文件“media.pk8”和一个对应的X509公钥证书文件“media.x509.pem”。其中，/C表示“Country Code”，/ST表示“State or Province”，/L表示“City or Locality”，/O表示“Organization”，/OU表示“Organizational Unit”，/CN表示“Name”。前面的命令生成的RSA公钥的e值为3，可以修改development/tools/make_key脚本来使用F4 (0×10001)作为e值（openssl genrsa的-3参数改为-f4）。
也可以使用JDK中的keytool来生成公私钥对，第三方APK签名一般都是通过keytool来生成公私钥对的。
可以使用openssl x509命令来查看公钥证书的详细信息： $ openssl x509 -in media.x509.pem -text -noout or, $ openssl x509 -in media.x509.pem -inform PEM -text -noout
还可以使用JDK中的keytool来查看公钥证书内容，但其输出内容没有openssl x509全面： $ keytool -printcert -v -file media.x509.pem
有了key之后，可以使用工具“build/tools/releasetools/sign_target_files”来对TargetFiles重新签名： $ build/tools/releasetools/sign_target_files_apks -d new_keys_dir -o target_files.zip target_files_resigned.zip 其中，new_keys_dir目录中需要有四个key（media, platform, shared, releasekey）。注意：这里的releasekey将代替默认的testkey（请参考build/tools/releasetools/sign_target_files脚本实现），也就是说，如果某个apk的Android.mk文件中的LOCAL_CERTIFICATE为testkey，那么在生成TargetFiles时是使用的build/target/proct/security/testkey来签名的，这里重新签名时将使用new_keys_dir/releasekey来签名。
uild/tools/releasetools/sign_target_files_apks是通过host/linux-x86/framework/signapk.jar来完成签名的。也可以直接使用host/linux-x86/framework/signapk.jar来对某个apk进行签名： $ java -jar signapk [-w] publickey.x509[.pem] privatekey.pk8 input.jar output.jar 其中，”-w”表示还对整个apk包(zip包）进行签名，并把签名放在zip包的comment中。
对于第三方应用开发者而言，对APK签名相对要简单得多。第三方应用开发一般采用JDK中的keytool和jarsigner来完成签名密钥的管理和APK的签名。
使用keytool来生成存储有公私钥对的keystore： $ keytool -genkey -v -keystore my-release-key.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000
查看生成的密钥信息： $ keytool -list -keystore my-release-key.keystore -alias mykey -v or, $ keytool -list -keystore my-release-key.keystore -alias mykey -rfc （注：获取Base64格式的公钥证书，RFC 1421）
导出公钥证书： $ keytool -export -keystore mystore -alias mykey -file my.der （注：二进制格式公钥证书，DER） $ keytool -export -keystore mystore -alias mykey -file my.pem -rfc （注：Base64格式公钥证书，PEM）
对APK进行签名： $ jarsigner -verbose -keystore my-release-key.keystore my_application.apk mykey
验证签名： $ jarsigner -verify -verbose -certs my_application.apk
在进行Android二次开发时，有时需要把build/target/proct/security下面的公私钥对转换为keystore的形式，可以参考这篇文章：把Android源码中的密码对转换为keystore的方法。
㈦ Android8.1源码下对APK进行系统签名
在Android8.1上面继续参考http://blog.sina.com.cn/s/blog_3e4774e30101e1y5.html这凳神森篇文章来对APK进行Android系统源码环境下的签名，发现签枣亩名时出现如下错误：
查了下资料，需要将命令由如下：瞎羡
修改为：
参考资料：https://ask.csdn.net/questions/684938
㈧ Android系统签名
有时候，我们开发的apk需要用到系统权限，需要在AndroidManifest.xml中添加共享系统进程属性：
这时候apk的签名就需要是系统签名(platform、shared或media)才能正常使用。
常用系统签名方式
这种方式比较麻烦，你需要有编译过的源码环境，并按如下步骤：
1、拷贝App源码到Android源码的packages/apps/目录下，且App源码是普通(Eclipse)格式的
2、配置Android.mk，在其中添加
3、使用mm编译App，生成的apk即系统签名
这种方式比在源码环境下签名简单，App可以在Eclipse或Android Studio下编译，然后给apk重新签名即可。
但这种方式在频繁调试的时候比较痛苦，即使写成脚本，也需要重复一样的操作。
相关文件
platform.x509.pem、platform.pk8、signapk.jar
文件位置
platform.x509.pem、platform.pk8:
signapk.jar:
signapk源码路径:
签名命令
步骤
1、将相关文件及源apk文件置于同一路径下
2、检查源apk包，去掉META-INF/CERT.SF 和 META-INF/CERT.RSA 文件
3、执行签名命令即可
让Android Studio集成系统签名，需要用到一个工具 keytool-importkeypair ，详见下文。
这个工具的作用是将系统签名的相关信息导入到已有的签名文件里。
工具的使用方法可以通过–help或README.textile来寻求帮助
platform.x509.pem、platform.pk8、keytool-importkeypair、demo.jks、signature.sh
我的做法是在App根目录新建Signature文件夹专门存放签名相关文件。
步骤
1、生成demo.jks签名文件
2、编写签名脚本signature.sh，内容如下：
为脚本文件添加可执行权限：
执行脚本：
3、配置builde.gradle
在android区域下(与defaultConfig同级)添加配置：
这样debug或release apk就带有系统签名了。
如果想直接Run app就是release版且带系统签名的apk，还需修改：
这样直接Run app就是带系统签名的release版apk了。
㈨ Android apk 系统签名
因工作需要对系统的wifi和以太网进行配置，需要获取友蚂春到系统权限以后才能进行操作，因此研究了物哪下对apk 进行系统签名以获取系统权限，其实本来打算如果root可以的话直接通过root的方式（设备已经root），后来找了半天发现没有api进行修改，无奈只能进行系统签名了，有童鞋知道root方式修改不妨告诉我一下。
这些文件可以问系统厂商获取，如果是原生系统可以到系统源码目录下获取。
如果报以下的错误 ,这时候就用到准备的libconscrypt_openjdk_jni.so 文件
为了检测我们的应用是否已经签名成功 可以获取系统权限，看看能否获取到。
结果:
在上一种方式中，我们成功对我们的apk进行了系统签名，并且能使用系统权限，但是必须每次打包出apk再进行签名 对调试很不方便，下面我们可以生成带有系统签名的签名文件，在项目中使用，就不需要每次手动进行签名。
bubble可以替换为自己喜欢的名称,这一步要输入密码，我尝试输入其他好耐不行，只能输入android。
bubble 可替换为自己喜欢的password和alias
到这里 两种对app进行系统签名的方式完成，如有不足，欢迎指出.
㈩ 如何让应用程序获得系统权限以及如何使用platform密钥给apk签名
Android中许多函数只能是系统程序或者有root权限的程序才可以调用，否则会有"Permission denied"异常。所以如果开发时要调用此类函数，必须授予程序root权限。下面是两种具体的实现方法
注：两种方法都不一定适用于所有android系统。
方法一：需要在清掘Android系统源码的环境下用make来编译：
在应用程序的 AndroidManifest.xml 中的 manifest 节点中加入 android:sharedUserId="android.uid.system" 这个属性
修改Android.mk文件，加入LOCAL_CERTIFICATE := platform这一行
使用mm命令来编译，生成的apk就有修改系统时间的权限了。
方法二：
同上，加入android:sharedUserId="android.uid.system"这个属性。
使用eclipse编译出apk文件，但是这个apk文件是不能用的。
用压缩软并漏件打开apk文件，删掉META-INF目录下的CERT.SF和CERT.RSA两个文件。 （这一步我跳过了（原本是无意的，后来发现下面也有提到），结果一样可以）
使
用目标系统的platform密钥来重新给apk文件签名。这步比较麻烦，首先找到密钥文件，在Android源码目录中的位置
是"build\target\proct\security"，下面的platform.pk8和platform.x509.pem两个文件。然
后用Android提供的Signapk工具来签名，signapk的源代码是在"build\tools\signapk"下，用法为"signapk
platform.x509.pem platform.pk8 input.apk
output.apk"，文件名最好使用绝对路径防止找不到，也可以修改源代码直接使用。
<此时这样最后得到的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，不过放到G3上安装直接提示"Package ... has no signatures that match
those in shared user android.uid.system"，这样也是保护了系统的安全。
最后说一下，这个android:sharedUserId属性不只可以把apk放到系统进程中，也可以配置多个APK运行在一个进程中，这样可以共享数据，应该会很有用的。