Android系统应用添加android:sharedUserId="android.uid.system"的作用及替代方案

一、添加与不添加该属性的作用差异 #

添加android.uid.system的作用 #

• 获得系统级权限：应用以系统用户身份运行，可访问普通应用无法触及的系统资源（如/system目录、系统核心API、受保护的系统服务）。
• 共享系统进程资源：和其他拥有相同sharedUserId的系统应用共享进程内存、数据目录，可直接访问彼此的组件或数据（需配合签名一致）。
• 绕过部分权限校验：部分危险权限（如WRITE_SECURE_SETTINGS、ACCESS_SUPERUSER）无需动态申请，直接拥有。

不添加该属性的作用 #

• 以普通应用身份运行：仅拥有Android权限模型下的普通权限，无法访问系统敏感资源，进程独立，数据隔离。
• 兼容性更好：不受系统签名限制，可像普通APK一样安装、更新，无需依赖ROM编译签名。

二、适用场景 #

适合添加的场景 #

• 定制ROM核心系统应用：比如系统设置、状态栏、桌面启动器这类深度整合进ROM的应用，需要直接操作系统底层资源。
• 需要访问系统敏感API的工具类应用：如系统备份工具、日志抓取工具，必须获取系统级权限才能完成核心功能。
• 与其他系统应用共享数据的场景：多个系统组件需要共享配置文件或状态数据时，通过相同sharedUserId实现跨应用数据访问。

不适合添加的场景 #

• 独立第三方应用：无需系统权限的普通应用，添加后会受系统签名约束，无法单独安装到非定制ROM设备。
• 需要频繁OTA更新的应用：绑定系统签名的应用无法通过普通应用商店更新，必须随ROM包推送更新，灵活性差。

三、Android 29（Android 10）及以上的替代方案 #

Android 10开始官方废弃了sharedUserId机制，推荐以下替代方案：

1. 系统签名+权限声明 #

• 在AndroidManifest.xml中声明需要的系统权限（如android.permission.WRITE_SECURE_SETTINGS），然后使用ROM的平台签名编译应用。
• 系统签名的应用即使不设置sharedUserId，依然可以获得对应系统权限，这是定制ROM中最常用的方式。

2. 特权应用配置（/system/priv-app目录） #

• 将应用放置在ROM的/system/priv-app目录下，同时在Manifest中添加android:privileged="true"属性。
• 该属性让应用获得特权应用身份，可申请更多系统权限，无需依赖sharedUserId。

3. 官方系统接口替代直接资源访问 #

• 优先使用官方提供的系统SDK接口或绑定系统服务实现功能，避免直接读写底层系统文件。
• 示例：通过Settings.Global接口修改系统设置，而非直接操作/data/system/settings.xml。

4. 组件级权限控制替代跨应用共享 #

• 若需要跨应用共享数据，通过Content Provider、Binder等组件设置严格的权限校验（如签名验证），替代sharedUserId的共享机制。
• 示例：在Content Provider的android:permission属性中指定自定义权限，要求访问方应用必须拥有该权限且签名一致。

内容的提问来源于stack exchange，提问作者Abhiroop Nandi Ray