91应用包名与系统UID有何区别

先说明这里的“包名”指什么

Android开发文档将application ID描述为类似com.example.myapp的字符串，用于设备和Google Play里的应用识别。日常资料常把它称为包名；代码里的namespace又是另一个开发配置，不应把所有带点字符串都归入同一栏。本文的包名统一指application ID。

显示名称是读者在图标或界面上看到的文字。档案里可以同时保存“显示名称：笔记甲”和“应用标识：com.example.notes”，但不能拿显示名称替后者填空。91两个数字可以出现在名称中，名称本身并不提供系统标识的换算公式。

UID回答的是资源由哪个系统身份访问

AOSP的应用沙箱文档说明，Android借助Linux用户身份机制隔离应用资源，为应用分配UID，并通过进程层面的身份和权限实施保护。因而UID适合解释某个运行环境中的访问边界，不是给产品起的公开名字。

这并不表示只要知道某个UID，就可以读取其私有数据；识别一个标识和获得访问权是两回事。本文讨论普通应用的基本沙箱模型，不将其简化成对全部系统应用、历史共享UID情形或所有安全机制的完整说明。

虚构例子：两个名称相同，记录仍不能合并

假设在同一教学环境里，笔记甲与笔记乙的显示名称都写“91笔记”。甲的application ID是com.example.notes，乙是com.example.notes.demo；记录中的UID分别为10123与10124。这些值全部为演示，不是从真实设备提取。

正确的表格有三列：显示名称、application ID、观察到的系统UID。两个显示名称一样，只能说明界面标签一致；两条application ID不同，说明这里不是同一个应用标识。UID另列并附观察环境，不能把末尾123或124当作版本号。

反过来，看到某条日志里的整数10123而没有包名，也不能从数字拼出com.example.notes。应回到该环境提供的包信息对应关系；缺少关联记录，就把“UID对应的应用未确认”写出来。

怎样把旧资料记录成可复查的条目

先记录字段原名和出处，例如“应用信息页显示名称”“发布资料中的application ID”“本机日志中的UID”，不要只留一个含义不明的“ID”列。接着注明平台、设备或用户环境与观察时间，再把具有直接对应依据的字段放到同一条目。

如果资料只提供application ID，就保留这一项，不要求为了档案完整而运行未知旧安装包。若不同材料给出的标识冲突，分开保留记录并说明来源；不要用名称相似或UID数字接近作合并理由。

整理软件历史时，应用标识解决的是“记录指向哪个应用”的部分问题，发布者、签名基准、版本与日期仍有各自字段。UID也不能证明某文件安全、某账号归属或某个历史品牌的当前运营状态。

一个三问练习

练习一：“显示名称含91，所以UID应为91。”不成立；显示名称与系统分配身份之间没有这条推导。练习二：“日志里两个UID接近，所以它们是前后版本。”也不成立；这里没有版本信息。

练习三：“两个条目显示名称相同，application ID不同，能否仅按名称去重？”不能。可保留两个候选，并在名称栏记录相同文字。练习的目的，是把身份、系统隔离与版本三个问题拆开，而不是凭一张表给任何应用做认证。

动手检查

1. 抄录原字段名称，先区分显示名、application ID与UID。
2. 为系统UID注明观察平台和环境，不脱离设备记录比较裸数字。
3. 只有直接的包信息关联，才把UID与某个应用标识放在同一行。
4. 用发布者、签名和版本的各自资料补充档案；未知项保留未知。

常见问题

资料来源与适用范围

• Android Developers：Configure the app module：支持application ID的用途、与namespace的区分；不证明演示名称对应真实产品。
• AOSP：Application Sandbox：支持Android使用UID与进程身份实施基本应用沙箱隔离；本文未将其写成完整安全保证。

继续阅读

• 91软件身份：名称、发布者与标识
• 91旧应用档案整理
• 返回91资料笔记