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%保护您的应用程序。你可以让它更难，但不是不可能。你的网络服务器可能会被破坏，黑客可以通过监控多个交易金额和你发送的关键字来找出你的关键字，黑客可以费力地通过源代码找出哪个代码是伪代码。

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

1.如何完全避免Android APK的反向工程？这可能吗？

AFAIK，没有任何技巧可以完全避免逆向工程。

@inazaruk也说得很好：无论你对代码做了什么，潜在的攻击者都可以以她或他认为可行的任何方式修改代码。你基本上无法保护你的应用程序不被修改。您在其中放置的任何保护都可以禁用/删除。

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

不过，你可以使用不同的技巧来提高黑客攻击的难度。例如，使用混淆（如果是Java代码）。这通常会大大降低逆向工程的速度。

3.有没有办法让黑客攻击变得更加困难甚至不可能？我还能做什么来保护APK文件中的源代码？

正如大家所说的，正如你可能知道的，没有100%的安全性。但谷歌内置的安卓系统的起点是ProGuard。如果您可以选择包含共享库，则可以在C++中包含所需的代码，等。如果您需要在每次构建时将外部本机库添加到APK的库文件夹中，那么你可以根据以下建议使用它。

将库放在默认为“libs”的本机库路径中您的项目文件夹。如果您为“armeabi”目标构建了本机代码，请将其放入在libs/armeabi下。如果它是用armeabi-v7a建造的，那么把它放在下面libs/armeabi-v7a。

<project>/libs/armeabi/libstuff.so

完全避免逆向工程是不可能的，但通过在内部使其更加复杂，攻击者可能更难看到应用程序的清晰操作，这可能会减少攻击向量的数量。

如果应用程序处理高度敏感的数据，则存在各种技术，这些技术会增加代码反向工程的复杂性。一种技术是使用C/C++来限制攻击者容易进行的运行时操作。有大量的C和C++库非常成熟，易于集成，Android提供JNI。

攻击者必须首先绕过调试限制，才能在较低级别上攻击应用程序。这增加了攻击的复杂性。Android应用程序应在应用程序清单中设置Android:debuggable=“false”，以防止攻击者或恶意软件轻易地进行运行时操作。

跟踪检查–应用程序可以确定调试器或其他调试工具当前是否正在跟踪它。如果被跟踪，应用程序可以执行任意数量的可能的攻击响应动作，例如丢弃加密密钥以保护用户数据、通知服务器管理员或其他此类类型的响应以试图自卫。这可以通过检查进程状态标志或使用其他技术来确定，如比较ptrace附件的返回值、检查父进程、进程列表中的黑名单调试器或比较程序不同位置的时间戳。

优化-为了隐藏高级数学计算和其他类型的复杂逻辑，利用编译器优化可以帮助混淆目标代码，使其不易被攻击者分解，从而使攻击者更难理解特定代码。在Android中，这可以通过使用NDK本地编译的库更容易地实现。此外，使用LLVM混淆器或任何保护器SDK将提供更好的机器代码混淆。

剥离二进制文件–剥离本机二进制文件是一种有效的方法，可以增加攻击者查看应用程序低级功能组成所需的时间和技能水平。通过剥离二进制文件，二进制文件的符号表被剥离，这样攻击者就无法轻松调试或反向工程应用程序。您可以参考GNU/Linux系统上使用的技术，如sstriping或使用UPX。

最后，您必须了解混淆和ProGuard等工具。

基本上这是不可能的。这永远不可能。然而，这是有希望的。你可以使用混淆器来实现，这样一些常见的攻击就更难执行了，包括：

重命名方法/类（因此在反编译器中，您可以获得像.a这样的类型）使控制流混乱（因此在反编译器中，代码很难阅读）加密字符串和可能的资源

我肯定还有其他的，但这是主要的。我在一家名为PreEmptive Solutions的公司工作，负责.NET混淆器。他们还有一个适用于Android的Java混淆器，一个叫做DashO的混淆器。

不过，困惑总是有代价的。值得注意的是，性能通常更差，通常需要一些额外的时间来发布。然而，如果你的知识产权对你来说非常重要，那么它通常是值得的。

否则，你唯一的选择就是让你的Android应用程序直接传递到一个承载你应用程序所有真实逻辑的服务器。这有其自身的问题，因为这意味着用户必须连接到Internet才能使用您的应用程序。

此外，不仅仅是Android有这个问题。这是每个应用商店的问题。这只是获取程序包文件有多困难的问题（例如，我不相信在iPhone上很容易，但仍然有可能）。

不，不可能！

你的三个问题围绕着100%保护应用程序不被阅读。原则上这是做不到的。而且，你在尝试做这件事上投入的越多，你的体验就会越差，最终，无论哪台机器只想读你的应用。想想HTTP的HTTPS本质上有多慢，因为需要处理安全层和数学。层数越多，有人打开它的速度就越慢，但如果你真的想让它被阅读，那就永远不可能，这就是为什么它会被打包并交付的原因。

一个简单的类比是将任何给定的隐藏对象交给某人。如果那个人能看到里面的东西，那么他们就可以拍一张照片，做一些完全类似的事情。更重要的是，在代码的情况下，有足够的专业人员可以创建该对象的精确副本，即使使用完全不同的过程。

假安全感

作为一个处理应用程序，你不应该关心你认为可以在二进制代码中创建的任何安全性，也不应该关心整个系统的完整性。假设来自客户机的任何信息都可能很快变得不可靠。保持应用程序简单、流畅、快速。相反，请担心您的服务器。例如，制定一个严格的通信协议以方便地监控服务器。这是我们唯一可以依靠的。

现在，坚持我的另一个想法，如何改进服务器端。。。

嘴上的钱

我正在开发支付处理应用程序

谷歌通过使用一种简单的财务方法来“保护”谷歌Chrome，在总体上成功地避免了恶意黑客，我引述如下：

我们有50000美元的奖励，奖励参与者可以在客户模式下使用Chromebook或Chromebox进行设备持久性测试

我们真正接近100%“安全”的最佳选择是为我们的金钱价值选择正确的斗争。也许大多数人都无法提供50k的奖励，但即使是1k的奖励也会有很长的路要走，而且这也比将这些钱投资于设计任何类型的bug捕捉器要便宜得多。

投资于人工智能来识别资金流动模式，以预测潜在风险并发现小的泄漏，这也比通过任何工程来防止这两种情况要便宜得多。

明显的例外

当然，这并不能保护我们免受“疯子”和“幸运的恶作剧者”的伤害。。。但什么都不会。同时，如果设置得当，当系统重新调整时，后一组只会享受很少的时间。而一个疯子，我们只需要担心，以防它大到有一个克星。无论如何，这将是一个伟大的故事！：）

太长；没有阅读；

换言之，也许一个更好的问题可以问你自己，而不是“如何避免在我的应用程序中进行逆向工程”，而是“如何设计一个更安全的支付处理系统”，并专注于你实际想要实现的目标：一个安全的系统。

很久以前，我曾尝试写更多关于以上所有内容的文章，以回答一些问题，比如为什么我在引号中加上“安全”和“保护”（它们到底是什么意思？）。

这里其他被否决的答案是正确的。我只是想提供另一种选择。

对于您认为重要的某些功能，您可以在应用程序中托管WebView控件。然后，该功能将在您的web服务器上实现。它看起来像是在您的应用程序中运行的。