嘿，我之前做.NET安卓应用时也踩过一模一样的坑——把敏感配置嵌在资源文件里，以为安全结果被轻松扒出来了。给你几个实际能用的方案，结合起来用防护效果会更好：

1. 利用系统级安全容器存储 #

安卓端的KeyStore是系统原生提供的敏感信息存储容器，加密后的内容只有你的应用能合法访问（只要权限配置正确）。具体做法：

• 先把client_id和client_secret用AES加密，再把加密后的内容+加密密钥一起存入KeyStore
• 每次需要使用凭证时，从KeyStore取出密钥和加密数据，解密后再调用接口
• 这种方式比自己写加密逻辑安全得多，因为KeyStore的密钥不会暴露在应用进程中

2. 后端动态下发临时凭证 #

别把核心凭证打包在客户端里！改成客户端启动时先请求你的后端服务：

• 后端先验证客户端合法性（比如校验应用签名、设备标识），通过后返回短期有效的临时凭证（比如1小时内有效）
• 客户端用这个临时凭证去调用第三方服务，就算被反编译，攻击者拿到的也只是过期很快的临时凭证，不会泄露永久的client_secret
• 后端还可以加限流、异常检测，防止恶意批量请求

3. 加密+代码混淆双重防护 #

如果必须把凭证存在客户端，一定要做加密+混淆的组合防护：

• 用自定义的复杂加密算法（别用Base64或简单异或，太容易破解）把明文凭证加密后，存在应用私有目录或数据库里，别放在资源文件中
• 开启安卓的ProGuard/R8代码混淆，把加密解密的方法名、变量名全部打乱，大幅增加攻击者逆向的成本
• 加密密钥别硬编码！可以结合设备IMEI、应用包名、版本号等动态生成，或者拆分多个片段放在代码不同位置，运行时再拼接还原

4. 把敏感逻辑完全移到后端 #

如果业务场景允许，尽量把需要使用client_id和client_secret的操作放在后端完成：

• 客户端只调用你的后端接口，后端再去对接第三方服务（比如OAuth认证、API调用）
• 这样客户端完全接触不到敏感凭证，从根源上避免泄露风险

重要提醒 #

没有绝对安全的客户端存储方案，所有客户端防护都是在增加攻击成本。核心的敏感信息，能放后端就别放客户端！

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