✨ 要点🔬 技术摘要
这篇论文就像是在给 Android 系统做了一次深度的“体检”和“人口普查”。为了让你更容易理解,我们可以把 Android 系统想象成一个巨大的、不断扩建的“超级城市” ,而API(应用程序接口)就是这座城市里供开发者使用的 公共设施 (比如路灯、红绿灯、图书馆、地铁站)。
开发者写 App,就像是在这个城市里盖房子或开店,他们必须依赖这些公共设施才能运作。
1. 核心问题:官方“地图”不准了?
在这个“超级城市”里,政府(Google)会发布几份不同的官方地图 (论文中称为 AALs ,即 Android API Lists),告诉开发者哪些公共设施是存在的、怎么用的。
这篇论文发现了一个大麻烦:政府发布的这几份地图,竟然互相打架,而且都不完全准确!
地图 A (JAR) :像是“编译后的蓝图”,只包含最终能用的东西,但有些细节被简化了。
地图 B (XML) :像是“时间轴记录”,告诉你哪些设施什么时候建了,什么时候拆了。
地图 C (TXT) :像是“源代码手稿”,保留了最原始的设计细节(比如泛型),但有些是还没编译的“半成品”。
地图 D (CSV) :像是“全量数据库”,包含了所有编译出来的东西,甚至包括一些为了内部测试或特殊语言生成的“隐形设施”。
研究发现: 如果你拿着地图 A 去盖房子,可能会发现地图 B 上有的设施你找不到;如果你拿着地图 C,可能会发现地图 D 里有些设施其实根本不存在。更糟糕的是,这四份地图里,只有大约 10% 的内容是完全一致的 。这意味着,如果你依赖其中某一份地图做研究或开发,你的结论可能是错的,就像拿着旧地图在新区迷路一样。
2. 奇怪的“幽灵设施”和“隐形通道”
论文还发现了两个有趣的现象:
幽灵设施(Synthesized APIs) : 有些设施在“全量数据库”(CSV 地图)里存在,但在真实的“城市”(手机设备)里根本找不到。这就像地图上画了一个“隐形地铁站”,实际上它只是编译器为了处理代码而临时生成的,现实中并不存在。如果开发者照着这个地图去修路,就会白忙一场。
隐形通道(Vendor Customizations) : 这是最关键的发现。除了 Google 建的“标准城市”,还有像小米、三星、华为这样的“区域开发商”(Vendor)。他们在自己的区域里偷偷建了很多专属设施 (比如小米的 MIUI 特有功能)。
现状 :这些专属设施没有 出现在任何一份官方地图里。
真相 :但是,大量的普通 App(甚至包括一些恶意软件)都在偷偷使用这些“隐形通道”!就像大家发现了一条只有本地人知道的捷径,虽然地图上没有,但大家都在走。如果研究者只看官方地图,就会完全忽略这些真实存在且被广泛使用的功能。
3. 真实世界的“探照灯”
为了验证地图准不准,研究团队做了两件实事:
实地勘测 :他们把“探照灯”(反射工具)照向了 9 台真实的手机(包括小米、三星和原生安卓)。
结果 :发现官方地图里说“存在”的某些设施,在真机上根本打不开;而真机上有的设施,地图里却完全没有。特别是那些“定制版”手机,里面藏着很多官方地图没记录的“私有设施”。
人口普查 :他们检查了 17,759 个真实的 App(包括开源软件、商业软件和病毒)。
结果 :开发者们其实很“狡猾”,他们不仅用官方地图上的设施,还大量使用那些“隐形通道”(厂商定制 API)和“地下通道”(非公开接口)。特别是商业 App 和病毒,非常喜欢用反射技术去调用这些地图上没有的功能。
4. 这对我们意味着什么?(结论与建议)
这篇论文给所有研究 Android 的学者和开发者敲响了警钟:
不要盲目相信单一地图 :以前大家做研究,随便挑一份官方地图就用,现在发现这会导致结论大相径庭。比如,有的工具说某个功能“不存在”,其实是因为它查的那份地图没更新,或者没包含厂商定制的内容。
地图是动态的 :官方地图的收录规则经常变。今天有的设施,明天可能就从地图里删了,但在真机上还能用。
关注“隐形”世界 :未来的研究不能只盯着 Google 的官方文档,必须把**厂商定制(Vendor Customizations)和 非公开接口(Non-SDK)**考虑进去。因为这才是真实世界中 App 运行的“潜规则”。
总结
这就好比我们要研究“中国交通状况”,如果只参考《国家公路网规划图》,而忽略了各省自己修的“乡间小路”和“临时便道”,那我们的研究结果肯定是不准确的。
这篇论文告诉我们:Android 的世界比官方地图显示的更复杂、更混乱,但也更真实。 想要真正理解 Android,必须把那些“地图上没有”的设施也找出来,才能看清全貌。
这是一篇关于 Android 官方 API 列表(Android API Lists, AALs)的实证研究论文。作者通过深入分析四个官方 AALs、真实设备上的 API 存在性以及真实世界应用中的 API 使用情况,揭示了当前 Android 研究中广泛使用的 API 列表存在严重的不一致性和不完整性问题。
以下是该论文的详细技术总结:
1. 研究背景与问题 (Problem)
Android 应用依赖于抽象核心系统功能的 API。这些 API 通常记录在 Android 源代码或 SDK 分发的多个官方文件中,统称为 Android API 列表 (AALs) 。
现有问题 :先前的 Android 研究往往依赖特定的 AALs,并默认它们是可互换的“事实真理”(Ground Truth)。
核心矛盾 :近期研究表明,不同的 AALs 会导致截然不同的研究结果。例如,某些在 AAL 中被标记为移除的 API,实际上在运行时的 Android 框架中仍然存在且可被调用;反之,某些 AAL 中包含的 API 在真实设备上并不存在。
研究动机 :这种不一致性严重威胁了基于 API 的 Android 分析(如兼容性检测、迁移研究、安全分析)的有效性和可复现性。
2. 研究对象与方法 (Methodology)
作者选取了四个在过往研究中最常用的官方 AALs 进行对比分析:
JAR List (android.jar) : SDK 中的编译类文件。
XML List (api-versions.xml) : 记录 API 生命周期(版本、弃用状态)。
TXT List (current.txt) : 记录源代码级别的 API 签名。
CSV List (hiddenapi-flags.csv) : 从 Android 9 开始引入,记录非 SDK 接口及其限制策略。
研究范围 :
时间跨度 :覆盖 6 个 Android 发布版本(API Level 28 至 33)。
设备验证 :在 9 台真实 Android 设备(包括 6 台定制系统如 MIUI/OneUI 和 3 台原生 Stock Android 虚拟机)上运行反射工具验证 API 存在性。
应用分析 :分析了 17,759 个真实世界应用(4,046 个开源应用、12,968 个商业应用、745 个恶意软件)。
研究问题 (RQs) :
RQ1 : AALs 中包含多少 API?它们随平台演进而如何变化?
RQ2 : 四个 AALs 之间的 API 内容有何差异(不一致性)?
RQ3 : AALs 中记录的 API 是否真实存在于 Android 设备上?
RQ4 : 真实应用主要使用了哪些 AALs 中的 API?
3. 关键发现与结果 (Key Findings & Results)
RQ1: AALs 的人口统计与演变
不稳定性 :API 包含规则随 Android 版本演变而剧烈变化。例如,在 API Level 31,TXT 列表中的类数量骤降 33.9%,原因是移除了大量 JDK 和第三方包,而非 Android 核心 API 的移除。
虚假移除 :部分从 AAL 中“移除”的 API(如 TXT 列表中的方法)实际上仍存在于源代码和运行时中,可通过反射调用。这给兼容性检测工具带来了误报(False Negatives)风险。
RQ2: AALs 的不一致性
极低的交集 :在 API Level 33,四个 AALs 共同包含的 Java API 仅占约 10% (类、字段、方法均如此)。
CSV 列表的特殊性 :CSV 列表包含的 API 数量远超其他列表(是 TXT 的 9 倍),其中 81.6% 的类是 CSV 独有的。这些独有类主要来源于:
故意隐藏(@hide, @removed 注解或非公开访问级别)。
非 Java 语言编译(AIDL, Protobuf, C/C++ 头文件等)。
外部库重打包(JDK 类、第三方库)。
其他列表的独有内容 :
XML :包含测试相关的 API(android.test.*)。
JAR :包含编译器生成的默认构造函数和从超类内联(Inlined)的方法。
TXT :保留源代码级别的泛型签名,而 CSV 仅包含字节码级别的签名。
内联成员问题 :某些常量和字段在源代码中定义在接口中,但在编译后的 JAR/XML 中被内联到具体子类中,导致 CSV 列表无法捕获这些成员。
RQ3: API 在真实设备上的存在性
CSV 最接近真实 :CSV 列表中的 API 在真实设备上的存在率最高(Stock Android 13 中仅 0.28% 缺失)。
JAR/XML/TXT 的缺失 :这些列表中大量缺失的 API 实际上是测试框架 API 或内联成员,它们在运行时并不作为独立实体存在。
厂商定制 API :定制系统(如 MIUI, OneUI)拥有大量非 AAL 记录的公共 API (Non-AAL APIs)。这些 API 通常用于厂商自带应用,但在官方文档和 AALs 中完全缺失。
RQ4: 真实应用中的 API 使用
核心 API 主导 :大多数直接调用(Direct Call)的 API 是四个 AALs 共有的核心 API。
非共享 API 的使用 :仍有相当一部分应用使用了仅存在于特定 AAL(如 CSV)中的 API。
额外调用 (Extra Calls) :应用大量使用 Android Support 和 AndroidX 库中的 API,这些通常不在官方 AALs 中。
厂商定制 API 的滥用 :研究发现开源和商业应用(包括恶意软件)都在调用厂商定制的 Non-AAL API。
反射调用 :商业应用和恶意软件比开源应用更倾向于使用反射调用非 SDK 接口(Non-SDK interfaces)。
4. 主要贡献 (Key Contributions)
首个深度实证研究 :首次系统性地对比了四个官方 AALs,揭示了它们之间的巨大差异和不稳定性。
揭示了“合成”与“内联”API :发现 AALs 中包含大量合成 API(如 Lambda 生成的类)和内联成员,这些在真实运行时中并不以列表形式存在。
厂商定制 API 的量化 :证明了厂商定制 API 在真实设备中广泛存在且被正常应用使用,但长期被研究忽视。
开源数据集 :发布了包含 AAL 数据集、分析工具源码和实验结果的完整资源(GitHub: sqlab-sustech/AAL-artifacts)。
5. 意义与建议 (Significance & Implications)
对研究者的警示 :
AALs 不可互换 :不能随意替换研究中的 API 列表,不同列表会导致完全不同的结论。
工具设计需改进 :现有的兼容性检测工具(如 PSDroid)若仅依赖单一列表(如 TXT),可能会漏报真实存在的 API 或误报已移除的 API。
需关注非 SDK 和定制 API :未来的研究必须考虑非 SDK 接口和厂商定制 API,因为它们对安全性和兼容性有重大影响。
具体建议 :
明确来源 :在研究中明确说明使用的 AAL 及其适用场景(如 TXT 适合核心功能,XML 适合测试,CSV 适合非 SDK 分析)。
解析源代码需谨慎 :解析 Android 源码提取 API 时,需考虑多语言编译(AIDL, C++)和内联成员的处理。
动态与静态结合 :由于静态列表的不完整性,建议结合动态分析(如反射、实际运行)来验证 API 的存在性。
总结
这篇论文打破了“官方 API 列表即真理”的迷思,证明了 Android 生态系统中的 API 知识是碎片化、动态变化且充满不一致性的。它呼吁社区重新审视基于 API 列表的研究方法,并强调了在分析 Android 系统时必须考虑厂商定制和非 SDK 接口的现实情况。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题,再试一次?
无垃圾邮件,随时退订。