“激活”的许可检查器的寿命地位。对于用户来说,多频繁才算过多?

发布于 2024-10-03 07:58:34 字数 1729 浏览 4 评论 0原文

我的应用程序是一种袖珍指南,包含全年的一些数据。我假设用户将至少使用该程序一次并通过互联网访问来激活许可证。或者至少这是我对 Android 许可系统如何工作的理解。我正在使用服务器管理策略。

它会定期检查许可证吗?有什么办法可以控制这个吗?我不希望我的用户处于无处可去的状态,应用程序已经且之前已激活,但突然在 1 周、1 个月、1 年等后,该应用程序开始限制应用程序本身的可用性,因为许可证无法无需再次验证。。我的应用程序将在网络访问不稳定的偏远地区使用(不能一直认为是理所当然的),供在那里居住数周甚至数月的人们使用。

我觉得我至少应该警告他们,每隔 X 周就会要求他们这样做。许可证制度真的那么严厉吗?

我知道我可以使用 ERROR_CONTACTING_SERVER 标志来处理 LicenseCheckerCallback 的 applicationError void 上的错误。 “VT”响应是否始终相同(无法在测试帐户/我的帐户上进行测试)?我只是好奇你们如何在自己的现实生活应用程序中处理这种情况。我在这里错过了什么吗?出于某种原因,我感觉我是。有什么“陷阱”吗?

//已编辑:

这是我现在正在尝试的代码:

// ServerManagedPolicy.java
private void setValidityTimestamp(String validityTimestamp) {
    Long lValidityTimestamp;
    try {
        lValidityTimestamp = Long.parseLong(validityTimestamp);
    } catch (NumberFormatException e) {
        // No response or not parsable, expire in one minute.
        Log.w(TAG, "License validity timestamp (VT) missing, caching for a minute");
        lValidityTimestamp = System.currentTimeMillis() + MILLIS_PER_MINUTE;
        validityTimestamp = Long.toString(lValidityTimestamp);
    }
    // added by me--->

    private static long maxLicense = 1000 * 3600 * 24 * 30; // ~ roughly 30 days
    private static long minLicense = 1000 * 3600 * 24 * 3;  // ~ roughly 3 days

    long lMax = System.currentTimeMillis() + maxLicense;
    long lMin = System.currentTimeMillis() + minLicense;
    if ((lValidityTimestamp > lMin) && (lValidityTimestamp < lMax)) {
        validityTimestamp = Long.toString(lMax);
    }

    // <--- added by me

    mValidityTimestamp = lValidityTimestamp;
    mPreferences.putString(PREF_VALIDITY_TIMESTAMP, validityTimestamp);
}

My app is a kind of a pocket guide with some data for the whole year. I'm assuming users will use the program at least once with Internet access to activate the license. Or at least that's my understanding of how the Android licensing system works. I'm using ServerManagedPolicy.

Does it check periodically for the license? Is there any way that I can control this? I don't want my users to be in the middle of nowhere, with an app already and previously activated and suddenly after 1 week, 1 month, 1 year etc. the app starts limiting the usability of the app itself because the license couldn't be verified again. My app is going to be used in remote places with erratic net access (can't be taken for granted all the time) by people who will live there for weeks, maybe months.

I feel I should at least warn them that they will be asked every X weeks to do that. Is the license system even that draconian?

I know I can handle the errors with the ERROR_CONTACTING_SERVER flag, on the applicationError void of LicenseCheckerCallback. Is the "VT" response always the same (can't test this on a test account/my account)? I was just curious about how you guys treat this situation on your own real life apps. Am I missing something here? For some reason I'm feeling I am. Is there any "catch"?

// EDITED:

Here is the code I'm trying right now:

// ServerManagedPolicy.java
private void setValidityTimestamp(String validityTimestamp) {
    Long lValidityTimestamp;
    try {
        lValidityTimestamp = Long.parseLong(validityTimestamp);
    } catch (NumberFormatException e) {
        // No response or not parsable, expire in one minute.
        Log.w(TAG, "License validity timestamp (VT) missing, caching for a minute");
        lValidityTimestamp = System.currentTimeMillis() + MILLIS_PER_MINUTE;
        validityTimestamp = Long.toString(lValidityTimestamp);
    }
    // added by me--->

    private static long maxLicense = 1000 * 3600 * 24 * 30; // ~ roughly 30 days
    private static long minLicense = 1000 * 3600 * 24 * 3;  // ~ roughly 3 days

    long lMax = System.currentTimeMillis() + maxLicense;
    long lMin = System.currentTimeMillis() + minLicense;
    if ((lValidityTimestamp > lMin) && (lValidityTimestamp < lMax)) {
        validityTimestamp = Long.toString(lMax);
    }

    // <--- added by me

    mValidityTimestamp = lValidityTimestamp;
    mPreferences.putString(PREF_VALIDITY_TIMESTAMP, validityTimestamp);
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

微暖i 2024-10-10 07:58:34

就我的两分钱来说,您可以定义您想要检查的时间段(比方说 3 天)。 3天后检查许可证,如果没有互联网,继续让用户使用它最多一周,否则应用程序将无法完整运行。或者只是保持其全部功能,直到再次建立连接,然后您可以检查并重置时间戳。许可证检查器只会在您指示时进行检查。

如果需要的话我可以澄清!

祝你好运

Just my two cents, you can define a period of time you would like to check (lets say 3 days). Check for the license after 3 days, if there is no internet, continue letting the user use it for lets say another week max or else the app will not be full functioned. Or just keep it full functioned until there is a connection again, then you can check and reset your time stamp. The license checker will only check when you tell it to.

I can clarify if need be!

Good luck

半衬遮猫 2024-10-10 07:58:34

大卫,简短的回答是这取决于你。

直接取自开发者文档。 “例如,服务器为应用程序的许可证有效期、重试宽限期和最大允许重试次数等提供建议值。”

根据您选择如何实施该政策,您可以选择自己问题的答案。

David, the short answer is it is up to you.

Taken directly from the developer document. "For example, the server provides recommended values for the application's license validity period, retry grace period, and maximum allowable retry count, among others."

Depending how you choose to implement the policy, your choosing the answer to your own question.

沫尐诺 2024-10-10 07:58:34

即使使用 ServerManagedPolicy,您的应用也将在您调用“checkAccess()”时检查许可证,如 检查许可文档的访问部分。如果从未进行过该调用,您的应用程序将继续无限期地工作 - 因此,如果您可以检测到您的用户处于无法合法地 ping 服务器获取许可证信息的情况,您可以将“checkAccess”调用包装在的条件。

页面下方提供了有关设置测试帐户以验证 LVL 功能的信息。我强烈建议充分利用该测试功能。

Even with the ServerManagedPolicy, your app will only check for a license when you call "checkAccess()" as described in the checking access section of the licensing doc. If that call is never made, your app will continue to work indefinitely - As such, if you can detect that your users are in a situation where they legitimately cannot ping the server for license information, you can wrap the "checkAccess" call in a condition for that.

Further down the page there's information on setting up test accounts to verify LVL functionality. I highly recommend making good use of that testing functionality.

孤独难免 2024-10-10 07:58:34

我非常简单地得到了这个问题的答案。通过 USB 将真实设备连接到您的计算机。在 ServerManagedPolicy.java 中编辑 LVL 库源代码,并使用 DateFormat.getDateTimeInstance(DateFormat.MEDIUM,DateFormat.MEDIUM) 添加 lValidityTimestamp 变量的日志语句。然后卸载您的应用程序以清除任何以前的许可证缓存时间戳,重新安装并运行您的应用程序。这会联系服务器,然后您的日志记录会显示答案。在我的测试中,VT 正好在 1 天后返回(检查许可证时)。

I got the answer to this very simply. Connect a real device via USB to your computer. Edit your LVL library source code in ServerManagedPolicy.java and add in a log statement for the lValidityTimestamp variable using DateFormat.getDateTimeInstance(DateFormat.MEDIUM,DateFormat.MEDIUM). Then uninstall your application to clear out any previous license cache timestamp, reinstall, and run your app. This contacts the server and then your logging statement reveals the answer. In my testing, the VT comes back to be exactly 1 day from now (when the license is checkes).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文