有些库的使用条件比较苛刻,要求同一签名的程序才可以获得访问权。此时即便是在AndroidManifest.xml中添加了相应的permission,依旧会得到没有xx访问权限的问题。比如android.permission.ACCESS_SURFACE_FLINGER 。

第一个方法简单点,不过需要在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\target\product\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运行在一个进程中,这样可以共享数据,应该会很有用的。

REF:http://labs.chinamobile.com/go.php?url=http%3A%2F%2Fdev.10086.cn%2Fblog%2F%3Fuid-49302-action-viewspace-itemid-907

Android通过共享用户ID来实现多个Activity进程共享

通过共享用户ID来实现多个应用程序使用同一个进程,这样也能使这些应用程序之间共享内存。

1. 同一Apk中的同一包中的多个Activity调用时进程状况验证

[1]创建Project:

project name: FirstProject

package : com.demo

默认Activity : MainActivity

[2]添加一个新的Activity:

name: SecondActivity

[3]修改布局。在MainActivity布局中添加一个Button,当点击此Button时启动SecondActivity。在SecondActivity的布局中放置一个Textview,以证明SecondActivity已启动。

[4]运行程序,查看此App进程情况:

USER:app_36 PID:8360 NAME:com.demo

[5]点击按钮,启动SecondActivity,再次查看进程情况:

USER:app_36 PID:8360 NAME:com.demo

结论:进程列表没有变化,两个Activity运行在同一进程中。


2. 同一Apk中的不同包的Activity调用时进程状况验证

[1]将SecondActivity挪到包com.demo.second中去,相应修改AndroidManifest.xml中的name为:com.demo.second.SecondActivity

[2]运行程序,查看此时进程情况:

USER:app_36 PID:10593 NAME:com.demo

[3]点击按钮启动SecondActivity,查看此时进程情况:

USER:app_36 PID:10593 NAME:com.demo

结论:进程列表没有变化,两个Activity运行在同一进程中。即进程name只受AndroidManifest.xml中manifset结点的package属性影响。


3. 同一Apk中Activity process属性修改后进程状况验证

[1]为SecondActivity添加process属性,其值为":abc",也可以随便是其他的":"开头的字符串,常见的名字是":remote":

           <!--Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->      <activity android:name="com.demo.second.SecondActivity" android:process=":abc"> </activity>     

[2]运行程序,查看进程情况:

USER:app_36 PID:12137 NAME:com.demo

[3]点击按钮,启动SecondActivity,查看进程情况:

USER:app_36 PID:12137 NAME:com.demo

USER:app_36 PID:12303 NAME:com.demo:abc

结论:进程表多了一项。两个Activity各自有一个进程,SecondActivity的进程名称为 包名+后缀。



4. 不同Apk中不同包名的Activity进程状况验证

[1]运行FirstProject:

USER:app_36 PID:12137 NAME:com.demo

[2]创建SecondProject:

project name: SecondProject

package:com.demo2

默认Activity:MainActivity

[3]运行SecondProject:

USER:app_37 PID:14191 NAME:com.demo2

结论:进程表多了一项。两个Activity各自有一个进程,同时其进程用户id、包名也不同,互不影响。



5. 不同Apk,签名相同、包名相同的Activity进程状况验证

[1]修改SecondProject的包也为com.demo,相应要修改AndroidManifest.xml内容。

[2]运行SecondProject,查看进程情况:

USER:app_36 PID:14944 NAME:com.demo

结论:进程表只有一项,但是实际上FirstProject此时已经被覆盖了,系统中只存在SecondProject了,因为模拟器调试时apk使用的签名key都是一样的,系统看到key一样,包名一样认为这个包就是FirstProject所以覆盖掉了。

可以通过DDMS复制/data/system/packages.xml查看一下内容:

           <!--Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->      <package name="com.demo" codePath="/data/app/com.demo.apk" system="false" ts="1279955425000" version="1" userId="10036">     


这个文件里面,package name都是唯一的,同时可以看到用户名是通过userId来决定的。


6.不同Apk,签名不相同,包名相同的Activity进程状况验证

[1]在Eclipse的Package Explorer导航树中选中FirstProject,点右键。

[2]Android tools-->Export Signed Application Package,按照向导创建一个用指定key签名的apk包。

[3]同样导出Second Project。

[4]切换窗口到模拟器,按Home键-->按Menu键-->设置-->应用程序-->管理应用程序-->SecondProject-->卸载。这是为了用命令行安装做准备。

[5]启动一个命令行窗口,执行adb install firstproject.apk,会提示成功安装。

[6]执行adb install secondproject.apk,提示安装失败。

结论:

1> 默认的Apk其安装时会分配新的UserId,即此时FirstProject以及SecondProject的UserId可以认为是不同的。

2> 包名不同,则签名key是否相同无所谓,两个apk都可以安装。【第4个实验】

3> 包名相同时,签名key相同则会覆盖【第5个实验】;签名不同则第二个apk安装会失败。【第6个实验】



7.不同Apk,Share User Id相同,包名不同时进程情况分析

[1]修改firstproject、secondproject的AndroidManifest.xml的manifset结点,增加属性

           <!--Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->      android:sharedUserId="com.demouser"     

[2]修改secondproject的包为com.demo2,不然其会覆盖firsetproject。

[3]运行firsetproject、secondproject,查看进程列表:

USER:app_35 PID:19993 NAME:com.demo2

USER:app_35 PID:20045 NAME:com.demo2

结论:

仍然存在两个进程。但是进程的用户名一样,说明shareUserId确实有效了,进程pid不相同。

再次导出/data/system/packages.xml,查看其内容,可以看到两个项目的UserId都是10035,确实是一样的:

           <!--Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->      <package name="com.demo" codePath="/data/app/com.demo.apk" system="false" ts="1279957484000" version="1" sharedUserId="10035"> <package name="com.demo2" codePath="/data/app/com.demo2.apk" system="false" ts="1279957473000" version="1" sharedUserId="10035">     



8.不同Apk,Share User Id相同,包名不同、指定Activity的process属性进程情况分析

[1]修改SecondProject的MainActivity的process属性,指定绑定到进程名为com.demo的进程上:

           <!--Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->      <activity android:name=".MainActivity" android:label="@string/app_name" android:process="com.demo">     

[2]运行firstProject、SecondProject,查看进程情况:

USER:app_35 PID:21387 NAME:com.demo

结论:两个Activity运行于同一个进程。



9.不同Apk,Share User Id相同,包名不同、签名key不同

经实验,安装第二个apk时会提示INSTALL_FAILED_UPDATE_INCOMPATIBLE错误,安装失败。

总结:

UserId不同时:

包名不同:

未设定process属性时,各自的Activity在各自的进程。即使process指定了包名,也不会和另一个用户的同名包共享进程。

包名相同:

签名相同:覆盖旧的同包名apk。签名不同:新的apk会安装失败。【签名key一般都是不同的】

UserId相同时:

包名不同:

未设定process属性时,各自的Activity在各自的进程。process属性指定,则可以共享进程。

包名相同:

签名相同:覆盖旧的同包名apk。签名不同:新的apk会安装失败。【签名key一般都是不同的】


参考:
[1]http://www.lhzhang.org/post/2010/09/Androide9809ae8bf87e585b1e4baabe794a8e688b7IDe69da5e5ae9ee78eb0e5a49aActivitye8bf9be7a88be585b1e4baab.aspx

更多相关文章

  1. Activity与Service是否处于同一进程
  2. 最新Android系统版本与API等级对应关系表
  3. android Accessibility系统自带语音助手打开第三方应用
  4. Android系统启动流程 -- bootloader、linux kernel、android
  5. Android利用系统提供的函数或常量判断版本大小

随机推荐

  1. Android系统的Binder机制之一——Service
  2. Android设计模式系列-适配器模式
  3. Android(安卓)SD卡创建文件和文件夹失败
  4. Android(安卓)AIDL进程IPC通信 一次就好
  5. Android:最全面的 Webview 详解
  6. Android之Adapter:连接后端数据和前端显
  7. 介绍一下android开发规范
  8. Android(安卓)ADB使用方法
  9. Android调用打印机
  10. android中随手指拖动滑屏