LibChecker 项目中对加固 APK 的 Compose 检测优化分析

在 Android 应用分析领域，LibChecker 作为一个优秀的开源工具，能够帮助开发者快速识别应用中使用的各种库和框架。近期项目团队针对加固 APK 中 Jetpack Compose 框架的检测问题进行了深入探讨和优化，这一改进对于应用分析具有重要意义。

背景与问题发现

在 Android 应用开发中，许多开发者会使用加固技术来保护自己的应用代码。传统的加固手段会对 APK 进行深度处理，使得常规的类扫描方法难以获取应用内部使用的库信息。然而，细心的开发者发现，即使在这些加固后的 APK 中，META-INF 目录下仍然保留了 Compose 框架的版本信息文件。

这一发现为检测加固应用是否使用 Compose 框架提供了新的思路。正常情况下，LibChecker 通过扫描应用的类信息来判断是否使用了 Compose，但对于加固应用这种方法往往失效。

技术实现方案

LibChecker 原本就具备通过 META-INF 目录检测 Compose 的能力，其实现逻辑主要检查以下条件：

1. 文件不是目录
2. 文件名以"androidx.compose"开头
3. 文件名以".version"结尾

但在实际应用中，团队发现某些特殊情况下的检测不准确。深入分析后发现，问题出在文件路径的处理上。在某些加固应用中，Compose 版本信息文件的完整路径为"META-INF/androidx.compose..."，而原有代码仅检查了基本文件名部分。

优化方案

针对这一问题，技术团队提出了更完善的检测逻辑：

1. 同时检查两种可能的路径格式
   • 直接以"androidx.compose"开头的文件名
   • 位于META-INF目录下，路径为"META-INF/androidx.compose..."的文件
2. 保留原有的".version"后缀检查

这种双重检查机制大大提高了在加固环境下的检测准确率，同时也保持了对常规应用的兼容性。

技术细节探讨

值得注意的是，在讨论过程中还提到了关于Compose预览Activity的问题。虽然检测预览Activity的存在可以作为判断依据，但从技术规范角度考虑：

1. 预览Activity理论上不应存在于Release版本的APK中
2. Google官方推荐使用debugImplementation方式引入预览工具
3. 依赖预览Activity检测可能会带来误判风险

因此，团队最终选择了基于版本信息文件的检测方案，这既符合技术规范，又具有更高的可靠性。

实际应用价值

这一改进对于以下场景特别有价值：

1. 分析加固应用的技术栈组成
2. 了解行业内的Compose采用率
3. 进行竞品技术分析
4. 应用兼容性测试

通过这一优化，LibChecker增强了对加固应用的分析能力，为开发者提供了更全面准确的应用分析数据。这体现了开源项目持续优化、追求技术精进的精神，也展示了社区协作解决实际问题的力量。