停用DexGuard后使用Jetpack Security能否保护源码中硬编码的敏感数据？

• Jetpack Security的EncryptedSharedPreferences/EncryptedFile 无法替代DexGuard的字符串混淆加密能力，二者防护维度完全不同
• 你示例中硬编码在源码里的PASSWORD-XXXXXXXX，只要他人拿到源码或者APK安装包，100%可以直接提取到该明文值，和你是否存到加密共享偏好没有任何关系
• 不存在「即便拿到源码也绝对无法解密查看敏感值」的客户端方案，所有防护手段都是提升逆向破解成本，只要成本高于破解收益即可满足绝大多数业务需求

Jetpack Security的作用是加密存储在用户设备本地的文件/共享偏好数据，避免设备被Root后攻击者直接读取本地存储的明文内容，它完全不会处理你编译到APK中的静态代码、硬编码字符串。
而你之前用DexGuard的核心能力是编译期字符串混淆加密，会把你源码里的硬编码字符串在打包时转换成密文，运行时才动态解密为明文，反编译APK只能拿到乱码密文，无法直接获取敏感值。

你给出的示例代码本身存在逻辑漏洞：

encryptedSharedPreferences.edit().apply {
    putString("MY_KEY","PASSWORD-XXXXXXXX")
}.apply()

你把明文敏感值直接写死在代码里，哪怕后续存到加密SP，这个明文已经被编译进APK的dex文件里了，攻击者只要用jadx等反编译工具打开APK，直接搜索PASSWORD-XXXXXXXX就能直接拿到值，加密SP在这个环节没有任何防护作用。

按照以下方案落地，防护效果可以和之前用DexGuard完全对齐：

• 优先避免敏感值硬编码：如果敏感值是后端接口分配的，建议走动态下发流程：用户首次启动应用时从加密接口拉取敏感值，运行时存在内存中，需要存储时再写入加密SP，从根源上避免敏感值出现在源码/APK包中。
• 必须硬编码的场景，用免费字符串混淆工具替代DexGuard：可以选择ProGuard自带字符串混淆配置、开源工具StringFog等方案，支持自定义加密算法，打包时自动加密所有标记的敏感字符串，运行时动态解密，能力和DexGuard的字符串加密模块一致。
• 搭配Jetpack Security做本地存储防护：经过字符串混淆工具加密的敏感值，运行时解密后再写入EncryptedSharedPreferences，同时覆盖静态代码、本地存储两个风险面，防护逻辑和你之前用DexGuard的方案完全一致。
• 进阶加固（可选）：如果对安全等级要求更高，可以把核心的字符串解密逻辑放到NDK层实现，编译为so文件后再对so做混淆加固，进一步提升逆向的成本。

内容的提问来源于stack exchange，提问作者SVK