我如何保护应用程序的所有资源、资产和源代码，使黑客无法以任何方式破解APK文件？

APK文件受SHA-1算法保护。您可以在APK的META-INF文件夹中看到一些文件。如果您提取任何APK文件并更改其内容并再次压缩，当您在Android机器上运行新的APK文件时，它将无法工作，因为SHA-1哈希永远不会匹配。

作为一个在支付平台（包括一个移动支付应用程序（MyCheck））上广泛工作的人，我想说，您需要将这种行为委托给服务器。移动应用程序中不应存储或硬编码支付处理器的用户名或密码（以其为准）。这是您最不希望看到的，因为即使您混淆了代码，也可以理解源代码。

此外，您不应在应用程序上存储信用卡或支付令牌。一切都应该再次委托给您构建的服务。这也会让你以后更容易遵守PCI标准，信用卡公司也不会像对待我们那样，让你喘不过气来。

当您将其放在最终用户手中时，没有什么是安全的，但一些常见的做法可能会使攻击者更难窃取数据。

将主要逻辑（算法）放在服务器端。与服务器和客户端通信；确保服务器和客户端之间的通信通过SSL或HTTPS进行安全；或者使用其他技术用于密钥对生成算法（ECC和RSA）。确保敏感信息保持端到端加密。使用会话并在特定时间间隔后使其过期。加密资源并按需从服务器获取资源。或者你可以制作一个混合应用程序，通过webview访问系统，保护服务器上的资源+代码

多种方法；很明显，您必须牺牲性能和安全性。

AFAIK，您不能再保护/res目录中的文件，因为它们现在受到保护。

然而，您可以采取一些步骤来保护源代码，或者至少保护它的功能（如果不是所有功能）。

使用ProGuard等工具。这些将使您的代码变得模糊，如果不是不可能的话，在反编译时更难阅读。将服务中最关键的部分从应用程序中移出，并隐藏在服务器端语言（如PHP）后面的Web服务中。例如，如果你有一个花费了一百万美元编写的算法。你显然不希望人们从你的应用程序中窃取它。移动算法，让它在远程服务器上处理数据，然后使用应用程序简单地向它提供数据。或者使用NDK将它们本机写入.so文件，这比apk更不容易被反编译。我认为目前还没有一个.so文件的反编译器（即使存在，也不如Java反编译器）。此外，正如@nikolay在评论中提到的，在服务器和设备之间进行交互时，应该使用SSL。在设备上存储值时，不要以原始格式存储。例如，如果您有一个游戏，并且您正在SharedPreferences中存储用户的游戏货币数量。假设是10000枚硬币。不要直接保存10000，而是使用（（货币*2）+1）/13这样的算法保存。因此，您将1538.53846154保存到SharedPreferences中，而不是10000。然而，上面的例子并不完美，你必须努力想出一个不会因舍入误差而失去货币价值的公式。您可以对服务器端任务执行类似的操作。现在举个例子，让我们来看看你的支付处理应用。假设用户必须支付200美元。不要向服务器发送一个200美元的原始值，而是发送一系列较小的预定义值，这些值加起来可以达到200美元。例如，在服务器上有一个文件或表，它将单词与值等同。假设查理相当于47美元，约翰相当于3美元。所以，你不需要寄200美元，而是可以寄查理四次，约翰四次。在服务器上，解释它们的含义并将其相加。这可以防止黑客向您的服务器发送任意值，因为他们不知道哪个单词对应什么值。作为一种额外的安全措施，您可以使用类似于第3点的公式，并每隔n天更改关键字。最后，你可以在你的应用程序中插入随机无用的源代码，这样黑客就可以大海捞针了。插入包含来自互联网的片段的随机类，或者只是用于计算诸如斐波那契序列之类的随机事物的函数。确保这些类可以编译，但不会被应用程序的实际功能所使用。添加足够多的这些虚假类，黑客将很难找到真正的代码。

总而言之，没有办法100%保护您的应用程序。你可以让它更难，但不是不可能。你的网络服务器可能会被破坏，黑客可以通过监控多个交易金额和你发送的关键字来找出你的关键字，黑客可以费力地通过源代码找出哪个代码是伪代码。

你只能反击，但永远不会赢。

如果你的应用程序如此敏感，那么你应该考虑服务器端的支付处理部分。尝试更改付款处理算法。使用Android应用程序仅用于收集和显示用户信息（即账户余额），而不是在Java代码中处理付款，请使用带有加密参数的安全SSL协议将此任务发送到您的服务器。创建一个完全加密和安全的API来与服务器通信。

当然，它也可能被黑客入侵，它与源代码保护无关，但考虑到它是另一个安全层，使黑客更难欺骗你的应用程序。

我知道一些银行应用程序正在使用DexGuard，它提供了类、字符串、资产、资源文件和本地库的混淆和加密。