通过共享用户ID来实现多个应用程序使用同一个进程

从很多方面来看,每个Android 应用程序都存在于它自己的世界之中:
• 默认情况下,每个应用程序均运行于它自己的Linux 进程中。当应用程序中的任意代码开始执行时,Android 启动一个进程,而当不再需要此进程而其它应用程序又需要系统资源时,则关闭这个进程。
• 每个进程都运行于自己的Java 虚拟机(VM)中。所以应用程序代码实际上与其它应用程序的代码是隔绝的。
• 默认情况下,每个应用程序均被赋予一个唯一的Linux 用户ID,并加以权限设置,使得应用程序的文件仅对这个用户、这个应用程序可见。当然,也有其它的方法使得这些文件同样能为别的应用程序所访问。

通过共享用户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":

<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查看一下内容:

<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结点,增加属性

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,确实是一样的:

<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的进程上:

<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

时间: 10-11

通过共享用户ID来实现多个应用程序使用同一个进程的相关文章

【移动开发】Android通过共享用户ID来实现多Activity进程共享

1.同一Apk中的同一包中的Activity调用时进程状况验证 [1]创建Project:    project name: FirstProject    package:com.demo    默认Activity:MainActivity [2]添加一个新的Activity:    name:SecondActivity [3]修改布局.在MainActivity布局中添加一个Button,当点击此Button时启动SecondActivity.在SecondActivity的布局中放置一

设置用户ID和设置组ID

与一个进程关联的ID有6个或更多,如下图所示: 与每个进程相关联的用户ID和组ID 实际用户ID 实际组ID 我们实际是谁 有效用户ID 有效组ID 附加组ID 用于文件访问权限检索 保存的设置用户ID 保存的设置组ID 由exec函数保存 实际用户ID和实际组ID标识我们究竟是谁,这两个字段在登录时取自口令文件中的登录项.通常,在一个登录会话间这些值并不改变,但是超级用户进程有方法改变它们. 有效用户ID,有效组ID以及附加组ID决定了我们的文件访问权限. 保存的设置的用户ID和保存的设置组I

无死角理解保存设置用户ID,设置用户ID位,有效用户ID,实际用户ID

最近在理解保存设置用户ID时,遇到一些问题,但是发现网上都没能把这个问题说清楚,通过自己的思考和查找资料,终于明白了,现在分享在这里共大家交流学习,如果有不正确的地方,欢迎指正 1,基本概念: 实际用户ID(RUID):用于标识一个系统中用户是谁,一般是在登录之后,就被唯一确定的,就是登陆的用户的uid 有效用户ID(EUID):用于系统决定用户对系统资源的权限.也就是说当用户做任何一个操作时,最终看它有没有权限,都是在判断有效用户ID是否有权限,如果有,则OK,否则报错不能执行.在正常情况下,

文件访问权限:更改用户ID

本文来探讨一下通过更改用户ID来获取合适的文件访问权限.由于更改组ID的规则与用户ID相同,我们在这里只探讨用户ID. 纸上得来终觉浅 先了解以下几个基本知识: 用户ID包括:实际用户ID.有效用户ID.保存的设置用户ID.其中保存的设置用户ID由exec函数保存. 实际用户ID标识我们究竟是谁,该字段在登录时取自口令文件中的登录项.通常,在一个登录会话期间该值不会改变,但root用户进程有方法改变它. 有效用户ID决定了我们的文件访问权限. 保存的设置用户ID在执行一个程序时包含了有效用户ID

ASP.NET MVC单点登录(多站点共享用户信息)

一.多站点共享用户信息解决方案: 采用分布式缓存Memcache模拟Session进行用户信息信息共享 1.视图部分 @{ Layout = null; } <!DOCTYPE html> <html> <head> <title>XX商城后台管理系统登录</title> <script type="text/javascript"> if (window.parent.window != window) { wi

Linux进程的实际用户ID和有效用户ID

在Unix进程中涉及多个用户ID和用户组ID,包括如下: 1.实际用户ID和实际用户组ID:标识我是谁.也就是登录用户的uid和gid,比如我的Linux以simon登录,在Linux运行的所有的命令的实际用户ID都是simon的uid,实际用户组ID都是simon的gid(可以用id命令查看). 2.有效用户ID和有效用户组ID:进程用来决定我们对资源的访问权限.一般情况下,有效用户ID等于实际用户ID,有效用户组ID等于实际用户组ID.当设置-用户-ID(SUID)位设置,则有效用户ID等于

linux下进程的实际用户ID(有效组)和有效用户ID(有效组ID)

实际用户ID(实际组ID):标识当前用户(所属组)是谁,当用户登陆时取自口令文件. 有效用户ID(有效组ID):用来决定我们(当前进程)对文件的访问权(即实际该进程的是以那个用户运行的). 一般情况下,进程的有效用户ID等于进程的实际用户ID,进程的有效用户组ID等于进程的实际用户组ID. 但是当可执行程序文件的文件模式(st_mode)中设置了“设置-用户-ID(set_user_id)位”时,进程的有效用户ID等于该可执行文件的拥有者ID. 同样的如果可执行文件的文件模式(st_mode)中

Oracle RAC中su: &#8203;无法设置用户ID: 资源暂时不可用

su: 无法设置用户ID: 资源暂时不可用 问题现象: 问题原因: 问题是出在:在/etc/security/limits.d目录下,rhel6和centos6下面多了个文件:90-nproc.config,以保证root用户无限制.此配置会覆盖主配置文件的设定.内容如下: 解决方法: 删除/etc/security/limits.d/90-nproc.conf 文件中1024那一行,或者将1024值改大,保存退出,立即生效!

进程控制(十一)---更改进程的用户ID和组ID

Linux提供了setuid函数和seteuid函数来更改与进程相关的用户ID,和进程相关的用户ID有“实际用户ID.有效用户ID和保存的设置用户ID” ====================================================== 函数原型: 函数参数: uid:要设置的用户ID 返回值: 调用成功时返回 0 调用失败时返回 -1 ==================================================== 当进程的有效用户ID是roo