小编Bil*_*Ape的帖子

我注意到"模板" proguard.cfg总是包含以下内容:

-keep public class * extends android.app.Activity
-keep public class * extends android.app.Application
-keep public class * extends android.app.Service
-keep public class * extends android.content.BroadcastReceiver
-keep public class * extends android.content.ContentProvider
-keep public class * extends android.app.backup.BackupAgentHelper
-keep public class * extends android.preference.Preference
-keep public class com.android.vending.licensing.ILicensingService

为什么这些特殊课程而不是其他课程

这是ProGuard不能"优化"的完整类列表吗？

每次按下Back我的应用程序中的按钮,我都会在LogCat中收到此异常:

Activity已泄露最初绑定的ServiceConnection com.android.vending.licensing.LicenseChecker@471cc039

造成这种泄漏的代码onCreate()是:

mLicenseCheckerCallback = new MyLicenseCheckerCallback();
mChecker.checkAccess(mLicenseCheckerCallback);

我如何摆脱这种泄漏？

我尝试不将MyLicenseCheckerCallback分配给成员,也许在活动开始时onPause()对回调的引用负责泄漏:

mChecker.checkAccess(new MyLicenseCheckerCallback());

但这并没有摆脱泄漏.

更新:感谢@ zapl在下面的评论,我查看了Google的LicenseChecker.java:

/** Unbinds service if necessary and removes reference to it. */
private void cleanupService() {
    if (mService != null) {
        try {
            mContext.unbindService(this);
        } catch (IllegalArgumentException e) {
            // Somehow we've already been unbound. This is a non-fatal error.
            Log.e(TAG, "Unable to unbind from licensing service (already unbound)");
        }
        mService = null;
    }
}

起初我以为我可能会忽略称它,但我仔细检查了,我 …

在安全性和设计准则去大篇幅概述的各种方法,使之更加难以攻击者危及应用内结算的实施.

特别值得注意的是.apk,即使通过Proguard进行模糊处理,对文件进行反向工程也是多么容易.因此,他们甚至建议修改所有示例应用程序代码,尤其是"已知入口点和出口点".

我发现缺少的是在单个方法中包含某些验证方法的任何引用,例如Security.verify()返回的静态boolean:一个好的设计实践(减少代码重复,可重用,更容易调试,自我记录等)但是所有攻击者现在需要做的就是找出那种方法并让它始终返回true......所以无论我使用它多少次,延迟或不延迟,随机或不随意,它都无所谓.

另一方面,Java没有像C/C++那样的宏,它允许减少源代码重复,但没有verify()函数的单个退出点.

所以我的问题:

众所周知的软件工程/编码实践与所谓安全设计之间是否存在内在争用？(至少在Java/Android /安全交易的背景下)

可以采取哪些措施来缓解"安全设计"的副作用,这种副作用似乎是"在脚下拍摄"过度复杂的软件,这些软件本来可以更简单,更易于维护和更容易调试？

你能推荐一些好的资料来进一步研究这个课题吗？

由于各种原因,我需要runOnUiThread()实际的WebView实例化和初始化.

这意味着它的底层HTTP连接也是在UI线程上进行的？

如果这是真的,是否可以将WebView的UI thead与HTTP连接线程分开？

如果有可能,实现这一目标的正确方法是什么？

BillingService类的注释建议:

您应该在使用之前修改和混淆此代码.

OK,但是什么必须进行修改？

班级名称？TAG用于记录？方法名称和数据成员？逻辑和程序流程本身？其他？

换句话说,我可以理解混淆的必要性,但是如何在不重写所有内容的情况下实现推荐(可能存在比不修改任何内容更糟糕的错误)？

我试着研究类似的问题,但那里提供的解决方案似乎不符合我的特殊情况:

我最初遵循配置和构建应用内结算示例应用程序的说明,使用Google开发人员帐户中的公钥替换安全密钥,并将软件包名称更改com.example为com.billtheape.

然后,我构建了一个非发布版本,并在我的Android手机上进行了"健全检查".一切顺利(除了访问Android Market服务器,当然,因为按设计它只适用于签名版本).

然后我尝试构建一个签名版本,但收到错误:

[2012-01-03 20:52:45 - Dex Loader] Unable to execute dex: 
  Multiple dex files define Lcom/android/vending/billing/IMarketBillingService;

[2012-01-03 20:52:45 - Dungeons] Conversion to Dalvik format failed: 
  Unable to execute dex: Multiple dex files define Lcom/android/vending/billing/IMarketBillingService;

现在的问题是,即使是"调试版本"构建也会产生相同的错误,无论我多少次尝试清理项目.

对于我所看到的接受的答案(我也检查过,但找不到任何可疑的东西),这对我来说并不像构建路径问题.所以我尝试了别的东西:

1. 退出Eclipse
2. 发现三个子目录下 %ANDROID_HOME%\extras\google\market_billing\gen\com:(1)android(2)例子(3)billtheape
3. 删除了子目录example.
4. 启动Eclipse并清理项目.

调试版本现在正确构建,但签名版本仍会生成相同的错误.事实证明,删除那个无关的子目录并不是什么魔术,而是重新启动Eclipse然后清理项目.

好的,所以至少我得到了"调试版本"的工作,但是签名版本的导出保持失败并出现同样的错误.

知道这个错误意味着什么,它为什么会发生以及如何修复它？

在我第一次实施应用内结算时,我慢慢地(但有条不紊地)进行了调查,我达到了实际运行市场结算示例应用程序的程度:应用程序已签名并上传到AM,"产品列表"已创建根据说明,Google 和手机都设置了测试帐户.

但是当我继续(成功)购买时,尽管在AM上选择了测试帐户,我仍然被提示用我的真实gmail帐户确认购买,我的真实信用卡链接到该帐户.

例如,在测试PayPal时,也可以使用伪CC号创建测试帐户,以便自由测试,不会给真正的CC系统带来负担.

这也适用于In-app Billing开发和测试吗？

更新:我在另一台设备上进行了测试,只设置了测试帐户,并确定Android Market行为错误,并回复了以下错误消息:

您找到的商品无法找到.

我知道该项目在那里并且它在Android Market中正确设置,因为这个错误永远不会在具有CC编号的真实账户的设备上发出(我收到了掩盖的CC编号的完美行为,总计和一个Accept & buy按钮).为什么Google会写出如此误导性的错误消息？

更新:我发现这个令人难以置信的线程,似乎部分回答了我的问题.除非谷歌从那以后引入了新的东西.

我们即将在Android电子市场上发布一个应用程序,其中包含针对订阅的应用内结算功能,可以在订阅期内解锁某些功能.

我的老板现在希望我实施不同数量的" 免费订阅",意思是:

1. "幸运用户"可以像任何其他客户一样从Android电子市场下载和安装应用程序(始终免费安装,但高级功能需要通过应用内结算付款).
2. "幸运用户"通过电子邮件接收一些密钥,允许他或她避免通过应用内结算结算流程(即实际支付).
3. 密钥只能使用一次.
4. 通过菜单项输入密钥,可以订阅X个月,就好像他实际通过应用内结算付款一样.

"密钥"基本上就像优惠券,但我在发布商的控制台中找不到任何此类选项.

您是否了解任何此类功能或实现上述内容的简单方法,而不会在我们(发布者)服务器上复制客户数据库？

谷歌的market_billing样品,只是像其他人一样为这一个,连接到远程服务IMarketBillingService,通过一个本地服务的包装,BillingService.

我知道服务具有在后台执行操作的优势,但IMarketBillingService不够远吗？

在洋葱上添加另一层有什么好处？

如果我尝试IMarketBillingService直接从我的主要活动,在UI线程中连接到远程,我将失去什么？

如果不建议IMarketBillingService直接在UI线程中连接到远程,可以BillingService用主活动中的另一个线程替换本地吗？

为了测试我不想释放功能的缘故还向广大市民,我想实现一个"秘密"菜单或菜单项.

通过"秘密"我的意思不是真正的秘密,但更多的是隐藏的或不可见的菜单,访问开发者(我)只能通过输入代码或其他机制.

如果最终用户发现它并尝试使用它这不是世界末日("他们做这白痴证明,但我找到了一个解决办法.").我只是不想通过提供尚未完全测试的功能而让毫无防备的无辜的最终用户失败.

关于如何解决这个问题的任何建议？(仅限Android 2.2及以上版本)