Android应用安全加固与攻防

引言：开放生态下的安全博弈

Android 作为开放的移动操作系统，为开发者提供了巨大的自由度和创新空间，但同时也使应用程序暴露在各种安全威胁之下。逆向工程、代码篡改、数据窃取、动态调试与注入、网络中间人攻击等手段层出不穷，对应用的知识产权、商业逻辑、用户数据安全以及整体生态构成了严峻挑战。

因此，应用安全加固成为许多应用（尤其是金融、游戏、内容付费、企业内部应用等）开发过程中不可或缺的一环。安全加固并非旨在构建绝对无法攻破的系统（这在现实中几乎不可能），而是通过增加攻击者的分析、破解和篡改难度与成本，起到威慑、延缓、防护的作用，从而保护核心资产和用户利益。

对于 Android 专家和架构师而言，需要具备扎实的安全意识：理解主流的攻击手段和威胁模型，熟悉各种安全加固技术的原理、效果与局限性，能够根据应用的风险等级和业务场景选择并实施恰当的加固策略（在安全性、性能、兼容性之间取得平衡），并持续关注攻防技术的演进。 安全不是一个孤立的功能点，而应是融入架构设计和开发全流程的系统性考量。

本文将深入探讨 Android 应用安全加固与攻防的关键方面：

  • 知己知彼： 了解常见的 Android 应用攻击向量；
  • 代码保护： ProGuard/R8 高级混淆、代码加密与加壳技术；
  • 资源防护： 资源混淆与加密；
  • 运行时防护（RASP）： 反调试、反篡改、反 Hooking、Root 与模拟器检测；
  • 网络安全强化： HTTPS 最佳实践与证书锁定；
  • 数据存储安全： 加密存储与密钥管理（Keystore）；
  • 安全编码实践： 防范常见漏洞；
  • 安全思维： 攻防的持续性与权衡。

一、知己知彼：常见的 Android 应用攻击向量

理解攻击者如何「下手」，是制定有效防御策略的前提。

逆向工程（Reverse Engineering）

目的： 分析应用的实现逻辑、窃取算法、提取 API 密钥或敏感字符串、寻找安全漏洞、移除广告或付费限制（破解）、制作外挂等。

流程（简化）：

  1. APK 解包： 使用 apktool 或类似工具将 APK 解压，得到 classes.dex 文件、资源文件、AndroidManifest.xml 等；
  2. DEX 反编译：
    • dex2jar： 将 DEX 文件转换为 JAR 文件；
    • JADX、JEB、Ghidra 等反编译器： 直接将 DEX 或 JAR 反编译为近似的 Java 或 Kotlin 源代码，可读性较高；
    • baksmali： 将 DEX 文件反汇编为 Smali 代码（Dalvik 字节码的文本表示），阅读和修改 Smali 是更底层的逆向方式；
  3. SO 库分析： 使用 IDA Pro、Ghidra、Hopper 等反汇编/反编译工具分析 lib/ 目录下的原生库（.so 文件），理解其 C/C++ 逻辑。

逆向工程基本流程示意：

+-----------+      Unzip       +-----------------------+     dex2jar/    +-----------+      Decompiler   +--------------+
|    APK    | ---------------> | classes.dex, res/,    | ------------>   |    JAR    | ----------------> | Java/Kotlin  | (Readable Code)
+-----------+                  | AndroidManifest.xml,  |     baksmali    +-----------+                   | Source Code  |
                               | lib/ (*.so)           | ------------>   |   Smali   |                   +--------------+
                               +-----------------------+                 +-----------+                   (Bytecode Text)
                                     |                                     | Modify & Reassemble
                                     | Analyze Native Libs                 V
                                     V                          +-----------------------+
                           +-----------------------+            | Modified Smali/DEX    |
                           | IDA Pro / Ghidra etc. |            +-----------+-----------+
                           +-----------------------+                        | Repackage with apktool
                                                                            V
                                                                    +-----------------------+
                                                                    | Repackaged/Tampered APK|
                                                                    +-----------------------+

代码/数据篡改（Code/Data Tampering）

目的： 修改应用行为（如绕过付费验证、游戏作弊、去除广告）、注入恶意代码（如窃取信息）、修改本地存储的数据（如游戏存档、用户配置）。

方法：

  • 静态修改： 反编译得到 Smali 代码或资源文件，进行修改（如修改判断逻辑、替换字符串、修改布局），然后用 apktool 重新打包，并用自己的签名重新签名 APK；
  • 动态修改： 通过内存读写工具（如 GameGuardian，通常需要 Root）在运行时修改内存中的数据或代码；
  • 本地数据修改： 直接修改应用存储在本地的文件（SharedPreferences XML、SQLite DB、普通文件），前提是能访问到这些文件（Root 或不安全的存储权限）。

动态分析与 Hooking

目的： 在应用运行时监控其行为、拦截方法调用、查看或修改参数/返回值、绕过安全检测、动态注入代码。

工具：

  • 调试器（Debugger）： JDWP（Java 调试线协议）、Native 调试器（GDB、LLDB）。应用需要开启调试模式（android:debuggable="true"）或被附加调试器（需要特定权限或漏洞）；
  • Hooking 框架：
    • Frida： 强大的动态插桩工具包，可以附加到运行中的进程，注入 JavaScript 脚本来 Hook Java 方法和 Native 函数，进行各种运行时操作，极其灵活和流行；
    • Xposed Framework： 基于修改 ART 运行时的框架，允许开发者编写模块（Xposed Module）来 Hook 系统范围或特定应用的方法，需要 Root 或定制 ROM。

原理： 通过修改进程内存中的函数指针、方法表或注入代码，实现对目标函数调用的拦截和控制。

网络拦截（Network Interception）

方法： 设置网络代理（如 Charles Proxy、Burp Suite、Mitmproxy），将设备流量导向代理服务器。如果应用未使用有效的 HTTPS 或证书锁定，代理可以解密、查看和修改 HTTPS 流量。

目的： 分析 API 协议、窃取 Token 或敏感数据、篡改请求/响应以绕过客户端限制。

其他常见攻击向量

  • 不安全数据存储： 直接读取存储在设备上未加密或权限设置不当的敏感信息（密码、密钥、Token、个人信息）；
  • 不安全组件暴露： 利用未受保护的导出组件（Activity、Service、Receiver、Provider）进行攻击，如 Intent 劫持/伪造、权限绕过、数据泄露、拒绝服务等。

二、代码保护：提升逆向工程门槛

让攻击者难以读懂和修改代码，是第一道防线。

代码混淆（Obfuscation - ProGuard/R8）

核心功能：

  • 缩减（Shrinking）： 移除未使用的类、方法、字段；
  • 优化（Optimization）： 对字节码进行优化（内联、常量折叠等）；
  • 混淆（Obfuscation）： 将类、方法、字段重命名为无意义的短名称（如 a、b、c），这是最基本的混淆。

高级配置与技巧：

  • 控制流混淆（Control Flow Obfuscation）： 一些高级混淆器（商业或自研）会改变代码的执行流程（如插入无效分支、使用跳转表代替 switch、方法拆分/合并），使得反编译后的代码逻辑极其混乱，难以理解。R8 自身也包含一些控制流优化，但通常不如专业混淆器深入；
  • 字符串加密： 将代码或资源中硬编码的敏感字符串（如 API Key、加密密钥、提示语）进行加密，运行时再解密使用。可以使用简单的异或、Base64 变种，或更强的对称/非对称加密。关键在于解密逻辑和密钥自身的保护；
  • 反射处理（-keep 规则）： 这是维护的难点。必须使用 -keep 规则保留那些通过反射、JNI、序列化、资源 XML 引用、WebView JSBridge 等方式访问的类、方法、字段，否则混淆后会导致运行时找不到目标而出错。需要仔细分析代码，精确编写 -keep 规则，避免因规则过于宽泛而降低混淆效果。使用 proguard-rules.pro；
  • 开启优化（-optimizations、-optimizationpasses）： R8/ProGuard 的优化步骤本身也能使代码更难理解；
  • 字典（-obfuscationdictionary、-classobfuscationdictionary）： 不建议使用容易猜到的字典，默认短名称通常足够。

测试： 必须进行充分测试！ 开启混淆（尤其是优化和高级混淆）后，务必在混淆后的 Release 包上进行全面的功能和回归测试，确保没有因混淆导致的功能异常。使用 Mapping 文件（mapping.txt）来解读混淆后的崩溃堆栈。

代码加密与加壳/加固（Packing/Shelling）

概念： 将应用的核心代码（DEX 文件）或关键原生库（SO 文件）进行加密或特殊处理，应用启动时由一个「外壳」（Shell）程序负责解密、修复并加载到内存中执行。

机制：

  • DEX 加密/隐藏： 加密 classes.dex，运行时由 Shell 解密到内存，然后通过自定义 ClassLoader 加载。或者将 DEX 数据隐藏在其他文件（如资源、SO 库）中；
  • SO 库加固： 对 SO 文件进行加密、压缩，或修改 ELF 结构（如加自定义 Section、抹去符号表），运行时由 Shell 进行解密、修复和加载（可能使用 dlopen 的替代或 Hook）；
  • 完整性校验： Shell 在加载前通常会校验自身或核心代码是否被篡改；
  • 反调试集成： Shell 本身通常会集成多种反调试、反 Hooking 技术。

优点：

  • 强力对抗静态分析： 加密后的代码无法被标准反编译工具直接分析；
  • 集成运行时防护： 将运行时检测与代码加载绑定。

缺点：

  • 性能开销： 启动时需要执行解密、加载操作，增加冷启动时间。运行时可能因为自定义加载器或指令修复略微影响性能；
  • 兼容性风险： 加壳技术（尤其是修改系统加载流程的）可能与某些 Android 版本、ART 虚拟机特性、甚至设备厂商的定制系统产生兼容性问题。系统升级可能导致加固失效或应用崩溃；
  • 无法根除内存 Dump： 核心弱点！ 无论壳多强，最终代码都需要在内存中解密并执行。攻击者可以通过调试、Hooking 或内存 Dump 技术，在运行时将解密后的代码或内存片段 Dump 出来进行分析。攻防的焦点在于阻止或干扰 Dump 过程；
  • 开发与调试复杂性： 加固后的应用调试困难，通常需要在开发阶段使用未加固版本。

商业加固服务： 市面上有许多提供加固服务的厂商（梆梆、爱加密、腾讯乐固、网易易盾、360 加固宝，以及国外如 DexProtector、Guardsquare（ProGuard/DexGuard））。它们通常提供更复杂、多层次的保护方案（多重壳、虚拟机保护 VMP、指令抽取等）。

加固是一把双刃剑，需要仔细评估：(1) 应用面临的实际威胁等级和代码/资产价值；(2) 加固带来的安全性提升程度（能否有效防御目标攻击者？）；(3) 对性能（启动、运行）和稳定性的影响；(4) 兼容性风险；(5) 成本（商业服务费用或自研投入）。通常用于对安全性要求极高的应用（金融、支付）或需要强力反破解/反外挂的游戏。

三、资源保护

除了代码，应用内的资源（图片、布局、配置、原生库）也可能被提取或篡改。

  • 资源混淆： 使用工具（如 AndResGuard）混淆资源名称和路径。例如将 res/layout/activity_main.xml 混淆为 res/l/a.xml，将资源 ID 名称混淆，增加反编译后理解资源用途和修改资源的难度；
  • 文件混淆/伪加密： 对 assets 或 res/raw 中的文件进行简单的变换（如异或、偏移）或伪加密，运行时再进行逆操作。可以防止被直接解压查看，但很容易被逆向分析破解；
  • 资源/Assets 加密： 对包含敏感信息的文件（如配置文件、密钥片段、数据模型、脚本、游戏资源）进行真正的加密（如 AES），运行时使用安全的密钥（见后文密钥管理）进行解密。

四、运行时应用自我保护（RASP）：检测与响应攻击

RASP 的目标是让应用在运行时具备「感知」和「抵抗」攻击的能力。

核心检测技术

Root/越狱检测：

  • 方法： 检查是否存在 su 等超级用户命令；检查特定 Root 管理应用包名；尝试读写系统保护区域；检查 Build 属性（如 test-keys）；检查是否存在 Magisk 等框架的特征；
  • 局限性： 道高一尺魔高一丈。Root 隐藏技术（如 Magisk Hide）和检测方法一直在对抗，没有 100% 可靠的检测方法，需要组合使用多种检测手段并保持更新。

模拟器检测：

  • 方法： 检查 Build 属性（ro.product.brand、ro.product.manufacturer、ro.product.model 是否包含通用模拟器名称如 generic、sdk、google_sdk、emulator、nox、mumu 等）；检查硬件名称（如 goldfish、ranchu）；检查是否存在模拟器特定文件或驱动；检查传感器（模拟器通常没有或数据异常）；检查 CPU 信息；
  • 局限性： 模拟器可以修改这些特征值来绕过检测。

调试器检测：

  • 方法：
    • 检查 AndroidManifest.xml 中的 android:debuggable 标志位（虽然可以被篡改）；
    • 调用 Debug.isDebuggerConnected()；
    • 检测 TracerPid 字段（在 /proc/self/status 中，非 0 表示被跟踪）；
    • 利用时间差：执行一段代码，测量其耗时，如果耗时远超预期，可能处于调试状态（调试器单步执行慢）；
    • 设置信号处理器捕获调试相关的信号；
  • 局限性： 这些检测点都可以被攻击者通过 Hooking 或修改内核来绕过。

Hooking 框架检测：

  • 方法：
    • 检测 Xposed Installer、Magisk Manager 等管理应用包名；
    • 检测 Xposed Bridge、Frida Server 等相关的特征文件、端口或进程；
    • 扫描内存中加载的库或类，查找 Hook 框架的特征签名；
    • 检查关键系统函数或应用自身方法的入口点是否被修改（Inline Hook 检测）。例如，比较方法入口指令是否是预期的，或者函数地址是否指向非预期的模块；
  • 局限性： Hook 框架和检测手段也在不断对抗升级，新框架可能无法被现有方法检测到，检测本身也可能被 Hook 掉。

应用完整性/防篡改检测：

  • 方法： 在运行时获取自身 APK 的签名信息（PackageManager.getPackageInfo(packageName, GET_SIGNATURES) 或 GET_SIGNING_CERTIFICATES），并将其与编译时嵌入应用内的一个硬编码或安全获取的正确签名进行比对。如果不一致，说明 APK 被重新打包签名过；
  • 关键： 如何安全地存储和获取「正确签名」。硬编码在代码中容易被逆向修改，可以考虑从服务器安全获取，或与其他校验（如 SO 库校验）结合。

响应策略

当检测到异常环境（Root、模拟器、调试、Hooking、篡改）时，应用可以采取以下措施：

  • 静默退出： System.exit(0)，相对友好，但不明确；
  • 强制崩溃： throw RuntimeException("Security violation")，更明确，可能会被上报到崩溃平台；
  • 功能降级： 限制或禁用敏感功能（如支付、登录、核心玩法）；
  • 数据清除： 清除敏感数据；
  • 网络隔离： 阻止应用与服务器通信；
  • 上报服务器： 将检测到的异常信息发送到后台进行监控和分析；
  • 自定义反制： （游戏常用）例如，让作弊玩家进入「神仙服」，或者使其操作失效。

考量

  • 平衡： 安全检测与用户体验、兼容性之间的平衡。过于严格的检测可能误伤在特殊（但合法）环境下使用的用户（如开发者、安全研究员）；
  • 性能： 运行时检测会带来一定的性能开销，需控制频率和复杂度；
  • 有效性： 认识到 RASP 无法做到绝对防御，目标是提高攻击门槛，优先防御常见、低成本的攻击手段；
  • 分层： 采用多种检测手段组合，增加绕过难度；
  • 更新： 攻防技术在演进，检测逻辑需要持续更新。

五、网络安全强化

保护应用与服务器之间的通信信道。

强制 HTTPS（基本要求）

  • 使用 TLS/SSL 加密所有网络通信；
  • 通过 res/xml/network_security_config.xml 配置网络安全策略，禁止明文传输（<domain-config cleartextTrafficPermitted="false">）。

配置示例：

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
</network-security-config>

在 AndroidManifest.xml 的 <application> 标签中引用：android:networkSecurityConfig="@xml/network_security_config"。

证书锁定（Certificate Pinning / Public Key Pinning）（高级防御手段）

目的： 防御针对 TLS/SSL 的中间人攻击（Man-in-the-Middle，MitM），特别是当攻击者能够获取到设备信任的 CA 证书（如企业内部网络、用户主动安装的抓包工具证书）时。

机制： 应用内置（硬编码或安全下发）服务器端证书的公钥信息（或整个证书的哈希值）。在 TLS 握手完成后，客户端额外校验服务器提供的证书链中是否包含预期的公钥/证书。如果不匹配，则中断连接。

OkHttp 实现： 使用 CertificatePinner.Builder() 配置需要锁定的域名和对应的公钥哈希值（sha256/BASE64 格式）。

val certificatePinner = CertificatePinner.Builder()
    .add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=") // Replace with actual SHA-256 hash of public key
    .add("backup.example.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=")
    .build()

val okHttpClient = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

巨大风险与挑战：

  • 证书更新 = 灾难： 如果服务器更换了证书（即使是合法的续期），而已发布的、锁定了旧证书的应用版本将无法与服务器建立连接，导致应用完全瘫痪；
  • 运维复杂度： 需要建立极其严格、可靠的证书管理和应用更新流程。必须提前部署好备用密钥（Backup Pins），并有机制在新证书上线前强制用户更新应用；
  • 动态配置： 一种缓解策略是应用启动时从一个绝对可信的端点（这个端点自身可能也需要被锁定或有其他校验机制）动态获取最新的 Pinning 配置，但这又引入了新的安全依赖。

谨慎使用！ 仅在面临高风险 MitM 威胁且能够承担并有效管理其运维复杂性和风险时才考虑。对于绝大多数应用，强制 HTTPS 并信任系统 CA 是足够的。

API 安全

不要在客户端进行敏感操作的最终授权判断。所有涉及权限、付费、数据修改的操作，都应由服务器端进行严格的身份认证和权限校验。客户端校验可以被轻易绕过。

六、数据存储安全

保护应用存储在本地的敏感数据。

原则： 不存储非必要的敏感数据；必须存储时，务必加密。

Android Keystore 系统（安全密钥管理的基石）

特性：

  • 提供一个安全的容器来生成和存储加密密钥（对称密钥 AES，非对称密钥 RSA/EC）；
  • 硬件支持： 在支持 TEE（Trusted Execution Environment）或 SE（Secure Element）的设备上，密钥的生成、存储和使用（加解密、签名）都可以在硬件安全模块内完成，密钥本身永远不会离开硬件，极大提高了安全性。可以通过 KeyGenParameterSpec.Builder.setIsStrongBoxBacked(true) 请求使用 SE；
  • 访问控制： 可以为密钥设置使用条件，如：仅用于加密/解密或签名/验签；需要用户身份验证（指纹、人脸、锁屏密码）后才能使用（setUserAuthenticationRequired(true)）；
  • 密钥防提取： 设计上防止密钥被操作系统或其他应用提取出来。

用法：

  1. 获取 KeyStore 实例（KeyStore.getInstance("AndroidKeyStore")）；
  2. 使用 KeyGenerator（AES）或 KeyPairGenerator（RSA/EC）并配合 KeyGenParameterSpec 生成密钥，指定别名（alias）和参数，密钥会自动存入 Keystore；
  3. 通过别名从 Keystore 获取密钥（keyStore.getKey(alias, null)、keyStore.getCertificate(alias).getPublicKey()）；
  4. 使用获取到的密钥配合 Cipher 进行数据的加解密。

Jetpack Security（androidx.security:security-crypto）（推荐使用的便捷封装）

目的： 简化使用 Android Keystore 进行文件和 SharedPreferences 加密的操作。

核心类：

  • EncryptedSharedPreferences： 创建一个加密的 SharedPreferences 实例，其内部自动使用 Keystore 生成的密钥对 Key 和 Value 进行加密，API 与普通 SP 类似；
  • EncryptedFile： 提供加密的文件读写流（openFileInput()、openFileOutput()），内部使用 Keystore 密钥进行流式加密。

优点： 极大降低了安全存储的使用门槛，隐藏了 Keystore 和 Cipher 的复杂细节。

数据库加密

  • SQLCipher for Android： 一个流行的开源库，提供对整个 SQLite 数据库文件的透明加密，需要引入依赖并进行配置；
  • Room + 自定义加密： 结合 Room 使用 SupportSQLiteOpenHelper.Factory，在数据写入/读取时，使用从 Keystore 获取的密钥对特定字段或整个数据库页进行加解密。复杂度较高，需要仔细处理性能影响。

七、安全编码实践回顾

许多安全问题源于编码阶段的疏忽。

  • 输入验证： 对所有外部输入（UI、Intent 参数、网络响应、文件内容）进行合法性、边界检查，防止注入、溢出等。

安全 IPC：

  • 保护导出组件： 明确设置 android:exported="false"，除非确实需要外部调用。如果导出，必须设置严格的 android:permission，并在代码中进行权限检查；
  • 校验 Intent： 处理接收到的 Intent 时，校验其 Action、Data、Component、Extras 是否符合预期，防止恶意构造的 Intent 攻击；
  • PendingIntent： 创建 PendingIntent 时，如果包含敏感数据，考虑设置 FLAG_IMMUTABLE（推荐）或明确指定目标 Component；
  • Broadcast： 应用内通信优先使用 LiveData、Flow 等可观察模式替代广播（LocalBroadcastManager 已废弃）。发送系统广播时，考虑设置接收权限。接收广播时，校验发送者身份（如果可能）。避免在广播中传递敏感信息；
  • Content Provider： 控制 URI 权限（android:grantUriPermissions），在 query/insert/update/delete 中进行权限检查。防止 SQL 注入（使用参数化查询，Room 默认如此）。

WebView 安全（重灾区）：

  • 限制 JSBridge： 如果必须使用 addJavascriptInterface，确保接口方法不暴露敏感功能，并对传入参数严格校验。考虑使用 @JavascriptInterface 注解。Android O+ 有更安全的 WebViewCompat.addWebMessageListener API。或者更常见的方式是使用 prompt 方式通信；
  • URL 校验： 拦截 shouldOverrideUrlLoading，通过动态下发规则，只允许加载可信的 URL；
  • 禁止文件域访问： setAllowFileAccess(false)；
  • 混合内容： 避免在 HTTPS 页面加载 HTTP 资源；
  • 及时更新： WebView 实现（通常是设备上的 Chrome 或 WebView 组件）可能存在安全漏洞，应用本身无法直接控制，但应提醒用户更新系统 WebView。

依赖安全： 定期更新第三方库，关注其安全公告。使用工具扫描依赖库是否存在已知漏洞（CVE）。

八、安全思维：攻防的持续性与权衡

  • 没有绝对安全： 必须认识到，任何加固措施都可能被更有经验、更有资源的攻击者绕过。安全是一个持续对抗、提高门槛的过程；
  • 分层防御（Defense in Depth）： 不要依赖单一的安全措施。组合使用代码混淆、运行时检测、数据加密、网络安全、后台校验等多层防护；
  • 风险评估与成本效益： 根据应用的具体业务、面临的威胁、受保护资产的价值，来决定投入多少资源进行安全加固。并非所有应用都需要银行级别的防护。过度加固可能带来不必要的性能损耗、兼容性问题和开发成本；
  • 保持更新与学习： 安全领域的技术和攻防手段日新月异，需要持续关注最新的安全漏洞、攻击技术、防御方法和工具。

九、结论：安全加固，任重道远

在开放的 Android 生态中，应用安全加固是保护应用自身及其用户的重要手段。它并非一劳永逸的解决方案，而是一个需要综合运用代码混淆与加密、资源保护、运行时自我防护（RASP）、网络通信安全、数据存储加密以及遵循安全编码规范的系统工程。

我们需要具备全面的安全视野，不仅要理解各种攻击向量和防御技术的原理，更要能够权衡利弊，根据实际风险选择恰当的加固策略组合，并有效管理这些策略带来的性能、兼容性和维护成本。同时，将安全意识融入开发流程，推动团队实践安全编码，并持续关注安全动态，是保障应用长期安全的关键。

安全加固是一场没有终点的博弈。通过不断提高攻击门槛，我们可以最大程度地保护应用的核心价值，维护用户信任，为业务的稳定发展保驾护航。

#Android #安全 #加固 #逆向防护

Read Next

Android Native Crash 及 Firebase 捕获方案详解

在 Android 开发中，应用崩溃可分为 Java 层崩溃（RuntimeException） 和 Native 层崩溃（NDK 相关，如 SIGSEGV）。Java 崩溃通常能被 Firebase Crashlytics 轻松捕获，但 Native 崩溃默认不会被 Firebase 记录，需要额外配置。

深入解析 Android 17 的无锁 MessageQueue

Android 17 引入了全新的无锁 MessageQueue 实现 DeliQueue，通过 Treiber 栈和最小堆的混合数据结构，彻底消除了困扰 Android 二十年的锁竞争问题，显著减少了 UI 卡顿。