Security and Design指南花了很长的篇幅概述各种方法，以使攻击者更难于破坏应用程序内计费的实现。
特别要指出的是，即使通过Proguard进行了混淆，对.apk文件进行反向工程也很容易。因此，他们甚至建议修改所有示例应用程序代码，尤其是“已知的入口点和导出点”。
我发现缺少对将某些验证方法包装在单个方法中的任何引用，例如返回Security.verify()的静态boolean:良好的设计实践(减少了代码重复，可重用，易于调试，自我记录等)，但是所有这些攻击者现在需要做的就是识别该方法，并使该方法始终返回true ...因此，无论我使用了多少次(延迟或不延迟，随机或不随机)，这都没关系。
另一方面，Java没有C/C++中的宏，它可以减少源代码重复，但没有verify()函数的单个退出点。
所以我的问题是:
在众所周知的软件工程/编码实践与所谓的安全性设计之间是否存在固有的争论？ (至少在Java/Android/安全交易中)
对于过度复杂的软件而言，可以做些什么来减轻“为安全而设计”的副作用，这些副作用本来可以“简单地操作自己的脚”，这本来可以更简单，更易于维护且更容易调试？
您可以推荐一些很好的资料来进一步研究该主题吗？
最佳答案
像往常一样，这是一个折衷。使您的代码更难以逆向工程/破解涉及使它的可读性和维护难度降低。您可以根据预期的用户群，自己在该领域的技能，时间/成本等来决定要走的距离。这并不特定于Android。观看this Google I/O presentation进行混淆和使代码防篡改的各个阶段。然后决定您愿意为自己的应用程序走多远。
另一方面，您不必混淆/强化等所有代码，而仅是处理许可的部分，等等。通常这只是整个代码库的一小部分，实际上并不需要经常更改它，以使您可能难以接受/维护它，等等。只需对它的工作方式进行一些说明，以便在两年后提醒自己:)。