Android之UID and PID

本文探讨了在Android中启动不同应用内的Activity时可能遇到的权限问题,详细介绍了避免PermissionDenial异常的方法,并解释了Uid机制及其在共享数据和服务中的应用。

本文系转载,转载的地方没看到作者信息,可能是转载的转载,BS转载不注明出处者。如果你是本文作者,或者知道本文出处,请告知,将补上出处信息!

我们经常在一个activity中去start另一个activity,或者与另一个acitivity的结果进行交互(startActivityForResult)。但有没有想过可能会出现的permission问题呢?如果你遇到了permission denial的Exception,那么你需要读读这篇文章啦。

我们在同一个application内部,可以随意的startActivity from Activity A to Activity B,而官方的文档中说startActivity可能会报NotFoundException,表示被start的Activity不存在。因此,我们很容易忽略另一个可能的Exception,Permission Denial。

当我们在不同的application中,如application A中的Activity去start一个application B中的Activity,也许你什么Exception都不会得到,也可能会直接Force Close掉。因为再Start Activity时,代码是有去检验permission的。

如下情况,可以成功startActivity而不会得到permission denial
1、同一个application下
2、Uid相同
3、permission匹配
4、目标Activity的属性Android:exported=”true”
5、目标Activity具有相应的IntentFilter,存在Action动作或其他过滤器并且没有设置exported=false
6、启动者的Pid是一个System Server的Pid
7、启动者的Uid是一个System Uid(Android规定android.system.uid=1000,具有该Uid的application,我们称之为获得Root权限)

如果上述调节,满足一条,一般即可(与其他几条不发生强制设置冲突),否则,将会得到Permission Denial的Exception而导致Force Close。

现在,我来解释一下Uid机制
众所周知,Pid是进程ID,Uid是用户ID,只是Android和计算机不一样,计算机每个用户都具有一个Uid,哪个用户start的程序,这个程序的Uid就是那个那个用户,而Android中每个程序都有一个Uid,默认情况下,Android会给每个程序分配一个普通级别互不相同的 Uid,如果用互相调用,只能是Uid相同才行,这就使得共享数据具有了一定安全性,每个软件之间是不能随意获得数据的。而同一个application 只有一个Uid,所以application下的Activity之间不存在访问权限的问题。

如果你需要做一个application,将某些服务service,provider或者activity等的数据,共享出来怎么办,三个办法。
1、完全暴露,这就是android:exported=”true”的作用,而一旦设置了intentFilter之后,exported就默认被设置为true了,除非再强制设为false。当然,对那些没有intentFilter的程序体,它的exported属性默认仍然是false,也就不能共享出去。
2、权限提示暴露,这就是为什么经常要设置usePermission的原因,如果人家设置了 android:permission=”xxx.xxx.xx”那么,你就必须在你的application的Manufest中 usepermission xxx.xxx.xx才能访问人家的东西。
3、私有暴露,假如说一个公司做了两个产品,只想这两个产品之间可互相调用,那么这个时候就必须使用shareUserID将两个软件的Uid强制设置为一样的。这种情况下必须使用具有该公司签名的签名文档才能,如果使用一个系统自带软件的ShareUID,例如Contact,那么无须第三方签名。
这种方式保护了第三方软件公司的利益于数据安全。

当然如果一个activity是又system process跑出来的,那么它就可以横行霸道,任意权限,只是你无法开发一个第三方application具有系统的Pid(系统Pid不固定),但是你完全可以开发一个具有系统Uid的程序,对系统中的所有程序任意访问,只需再Manufest中声明shareUserId为 android.system.uid即可,生成的文件也必须经过高权限签名才行,一般不具备这种审核条件的application,google不会提供给你这样的签名文件。当然你是在编译自己的系统的话,想把它作成系统软件程序,只需在Android.mk中声明 Certificate:platform则可以了,既采用系统签名。这个系统Uid的获得过程,我们把它叫做获得Root权限的过程。所以很多第三方系统管理软件就是有Root权限的软件,因为他需要对系统有任意访问的权限。那么它的Root签名则需要和编译的系统一致,例如官方的系统得用官方的签名文件,CM的系统就得用CM的签名文件。

<think>好的,我现在需要帮助用户解决关于使用平台签名(platform signature)的Non-preload应用加入共享UID(shared UIDandroid.uid.system,并结合PackageInstaller和setMultiPackage的问题。首先,我需要回顾用户之前的讨论和提供的引用内容,确保理解问题的背景和相关技术点。 用户之前的问题涉及到PackageInstaller和setMultiPackage的使用,特别是在安装多个独立APK时的配置和注意事项。现在用户的问题转向如何为Non-preload应用使用平台签名,并设置共享UIDandroid.uid.system,这可能涉及到系统权限和安装过程中的签名验证。 首先,我需要明确几个关键点: 1. **Non-preload应用**:通常指不是预装在系统镜像中的应用,需要用户自行安装。 2. **平台签名**:使用与系统相同的签名密钥,通常由设备制造商持有,用于系统应用。 3. **共享UID**:允许应用共享同一个Linux用户ID,从而共享数据和权限。android.uid.system是系统级别的UID,通常只有系统应用可以使用。 4. **PackageInstaller和setMultiPackage**:用于安装多个APK包,可能需要处理多个应用的签名和权限问题。 接下来,我需要参考用户提供的引用内容。引用[1]提到了Package的解析过程,特别是解析APK的资源和清单文件,但未涉及代码的解析,这可能在安装阶段相关。引用[2]是一个SELinux错误,可能与权限或签名有关。引用[3]涉及SAP UI5的组件预加载,可能与当前问题无直接关联,但用户可能希望了解如何生成签名后的应用。 用户的问题核心在于如何正确配置Non-preload应用使用平台签名并设置共享UID,这可能涉及以下步骤: 1. **应用配置**:在AndroidManifest.xml中声明sharedUserId。 2. **签名配置**:使用平台签名密钥对应用进行签名。 3. **安装权限**:处理安装时的权限问题,可能需要系统权限或使用PackageInstaller的特殊配置。 用户提到与PackageInstaller和setMultiPackage相关,可能是在安装多个共享UID的应用时需要同时处理它们的签名和安装流程。结合之前的回答,setMultiPackage用于多APK安装,但需要注意签名一致性和权限问题。 可能的挑战包括: - 如何确保应用使用平台签名,特别是对于Non-preload应用,可能需要系统权限才能安装。 - 处理共享UID时的权限冲突,特别是android.uid.system通常仅限系统应用使用。 - 使用PackageInstaller进行安装时的配置,可能需要系统级权限或特殊API。 此外,用户可能需要处理SELinux策略问题(如引用[2]中的错误),确保应用在安装和运行时具有正确的安全上下文。 接下来,我需要组织这些思考,形成结构化的回答,涵盖配置步骤、签名方法、安装注意事项以及可能遇到的问题和解决方案。同时,需要引用用户提供的引用内容中的相关部分,如Package解析过程可能影响安装时的验证步骤,但需要明确与当前问题的关联性。 最后,生成相关问题,帮助用户进一步探索相关主题,如系统签名流程、共享UID的权限管理、SELinux策略调整等。</think>以下是针对**Non-preload应用使用平台签名并设置`android.uid.system`共享UID**的完整解决方案,结合`PackageInstaller`与`setMultiPackage`的使用场景: --- ### 一、核心实现步骤 #### 1. **应用配置**:在`AndroidManifest.xml`中声明共享UID ```xml <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.nonpreloadapp" android:sharedUserId="android.uid.system"> <!-- 关键声明 --> </manifest> ``` - **限制条件**: - 必须使用**平台签名证书**(如`platform.pk8`和`platform.x509.pem`) - 仅适用于系统级应用或具有**系统权限**的设备[^1] #### 2. **签名配置**:使用平台密钥签名 ```bash # 使用Android签名工具进行签名 java -jar signapk.jar platform.x509.pem platform.pk8 app-unsigned.apk app-signed.apk ``` - **验证签名**: ```bash keytool -printcert -jarfile app-signed.apk | grep "Owner:" # 输出应为平台证书持有者信息(如CN=Android) ``` #### 3. **安装权限配置**:`PackageInstaller`的特殊处理 ```java // 创建多包安装会话(需要系统权限) PackageInstaller.SessionParams params = new PackageInstaller.SessionParams( PackageInstaller.SessionParams.MODE_INHERIT_EXISTING); params.setMultiPackage(true); // 设置安装器身份为系统级(需系统权限) params.setInstallerPackageName("android"); ``` #### 4. **安装会话中处理共享UID** ```java // 子会话创建时需携带签名验证信息 PackageInstaller.SessionParams childParams = new PackageInstaller.SessionParams( PackageInstaller.SessionParams.MODE_FULL_INSTALL); childParams.setInstallFlags(PackageManager.INSTALL_ALLOW_TEST); // 验证父会话与子会话签名一致性 if (!verifySignatureConsistency(parentSessionId, childSessionId)) { throw new SecurityException("签名不一致"); } ``` --- ### 二、关键技术难点解析 #### 1. **签名一致性验证** - **实现逻辑**: ```java private boolean verifySignatureConsistency(int parentSessionId, int childSessionId) { PackageInstaller.Session parentSession = packageInstaller.openSession(parentSessionId); PackageInstaller.Session childSession = packageInstaller.openSession(childSessionId); // 获取APK签名信息(需反射访问内部API) Signature[] parentSigs = parentSession.getSignature(); Signature[] childSigs = childSession.getSignature(); return Arrays.equals(parentSigs, childSigs); } ``` - **注意事项**: - 需要系统权限才能访问`Session.getSignature()` - 反射调用需适配不同Android版本[^1] #### 2. **SELinux策略适配** 若出现类似`selinux_android_setcontext`错误(如引用[2]): ```bash # 在设备端添加SELinux规则 type=1400 audit(0.0:xx): avc: denied { set } for pid=xxx comm="installd" scontext=u:r:system_server:s0 tcontext=u:r:platform_app:s0 ``` - **解决方案**: ```te # 在system/sepolicy/private/system_server.te中添加 allow system_server platform_app:process { set }; ``` --- ### 三、与`setMultiPackage`的集成 #### 1. **多包安装场景下的特殊处理** ```java // 父会话配置 params.setMultiPackage(true); params.setInstallFlags(PackageManager.INSTALL_ALLOW_SHARED_USER_ID); // 子会话需携带额外元数据 Bundle extras = new Bundle(); extras.putString(PackageInstaller.EXTRA_SHARED_USER_ID, "android.uid.system"); childSessionParams.setExtras(extras); ``` #### 2. **安装结果验证** 在广播接收器中检查`EXTRA_SHARED_USER_ID`: ```java public class InstallReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { String sharedUserId = intent.getStringExtra( PackageInstaller.EXTRA_SHARED_USER_ID); if (!"android.uid.system".equals(sharedUserId)) { // 处理配置失败 } } } ``` --- ### 四、限制条件与替代方案 | 场景 | 可行性 | 说明 | |--------------------|--------|----------------------------------------------------------------------| | 非系统ROM设备 | ❌ | 需要平台签名和系统级权限 | | 自定义系统镜像 | ✅ | 需将APK预置到`/system/priv-app`目录 | | 通过ADB安装 | ⚠️ | 需`adb root`权限且设备已解锁Bootloader | | 动态安装(非预装) | ⚠️ | 需实现系统级安装器并通过`PackageInstaller`特权接口操作[^1] | --- ### 五、常见问题排查 1. **INSTALL_FAILED_SHARED_USER_INCOMPATIBLE** - **原因**:已存在相同UID但签名不一致的应用 - **解决方案**: ```bash adb uninstall com.existing.app # 卸载冲突应用 ``` 2. **INSTALL_PARSE_FAILED_NOT_APK** - **可能原因**:使用`setMultiPackage`时未正确分割APK文件 - **验证方法**: ```java // 检查子会话APK类型 if (childParams.mode != MODE_FULL_INSTALL) { throw new IllegalArgumentException("子会话必须为完整APK"); } ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值