scorpio28's Forum Posts

  • 9 posts
  • You do not have permission to view this post

  • Thanks for your reply pinkie, what you said makes perfect sense with regards my own game. It's odd though why I can no longer access the privacy policy of any other games either - for example, if I click on angry birds privacy policy it takes me to that same blank page, as it does if I click on clash of clans privacy policy, etc - I assume I'm stuck in testing mode but not entirely sure how you get out of it. Out of curiosity, I tried removing testers and unticking myself from the list, tried restarting my phone as well - but nothing works. The answer is probably on Google Play console I'll see if I can fathom it out.

  • After rolling out my game on alpha internal testing, it took a day or two for it to be published on Google play store. Everything looked fine and the game installs and runs perfectly on my phone. However, when I clicked on the privacy policy icon under contact developer, instead of going to my privacy policy, it goes to a blank screen instead. I tried uninstalling my game, reinstalling it, restarting my phone, clearing my cache, etc - and nothing works, everytime I click on my privacy policy icon it goes to a blank screen, even though the link to my privacy policy works fine when I type in the https on a new page. What's odd is that previously I have always been able to access the privacy policy of games on Google play - and now I cannot; it appears every privacy policy of every game on Google play now takes me to a blank page. What's strange is I tried going incognito and lo and behold when I clicked on the privacy policy icon on my game and that of others - this time it worked, it went straight to the privacy policy. I can't find any information about why this is happening, my only assumption is you can't access the privacy policy of apps when you are an internal tester on Google play console? It seems strange as part of the testing process is surely to make sure the link to your privacy policy works? Anyone else had problems accessing their privacy policy when on internal testing?

  • Unity developers are apparently encountering the same problem so at least it's not just specific to Construct 3. Which kind of gives you some reassurance. But it doesn't give you much confidence to release your games, especially if you plan to charge people to download them. Nobody wants complaints, bad reviews and demands for a refund due to constantly crashing games or games which won't load after they've paid for them. It kind of knocks your confidence in releasing your games. My only hope is that Construct 3 recognise the importance of being as up-to-date as possible with regards publishing on Google Play and update their systems accordingly so users can continue to aspire to publishing one day on Google Play. They must understand a lot of people are in it to make money from their creations so it's vitally important the various game engines are absolutely up-to-date with the requirements of Google Play, apple app store etc. If it becomes apparent that publishing on Google Play is no longer an option for example, I think a lot of people would simply not bother making games as if you can't publish them and potentially make money, what's the point?! Currently the 9 greylisted APIs may not be a barrier to publishing the games but (1) how many devices out there currently would not be able to download apps with greylisted APIs?, especially after those people have paid for them, and (2) how long before those 9 greylisted APIs become blacklisted and the game either gets kicked off Google Play altogether or it becomes impossible to download?! It's all rather demoralising after putting in so much hard work and getting this far! 😪

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Unsupported

    9 warnings identified

    The following APIs are greylisted and Google can’t guarantee that they will work on existing versions of Android. Some may be already be restricted for your target SDK

    API Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;->selectionAction(III)Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;

    2 occurrences identified. Only unique stack traces are shown.

    API Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;->selectionAction(IIILandroid/view/textclassifier/TextClassification;)Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;

    2 occurrences identified. Only unique stack traces are shown.

    API Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;->selectionModified(II)Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;

    2 occurrences identified. Only unique stack traces are shown.

    API Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;->selectionModified(IILandroid/view/textclassifier/TextClassification;)Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;

    2 occurrences identified. Only unique stack traces are shown.

    API Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;->selectionModified(IILandroid/view/textclassifier/TextSelection;)Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;

    2 occurrences identified. Only unique stack traces are shown.

    API Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;->selectionStarted(I)Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;

    2 occurrences identified. Only unique stack traces are shown.

    API Landroid/view/textclassifier/logging/SmartSelectionEventTracker;-><init>(Landroid/content/Context;I)V

    2 occurrences identified. Only unique stack traces are shown.

    API Landroid/view/textclassifier/logging/SmartSelectionEventTracker;->logEvent(Landroid/view/textclassifier/logging/SmartSelectionEventTracker$SelectionEvent;)V

    2 occurrences identified. Only unique stack traces are shown.

    API Landroid/content/Context;->bindServiceAsUser(Landroid/content/Intent;Landroid/content/ServiceConnection;ILandroid/os/Handler;Landroid/os/UserHandle;)Z

    1 occurrence identified

  • This is the information on Google Play console :

    Android Developers

    SIGN IN

    Google Play

    Android Developers

    Google Play

    Guides

    Restrictions on non-SDK interfaces

    Starting in Android 9 (API level 28), the platform restricts which non-SDK interfaces your app can use. These restrictions apply whenever an app references a non-SDK interface or attempts to obtain its handle using reflection or JNI. These restrictions were put in place to help improve the user and developer experience and reduce the risks of crashes for users and emergency rollouts for developers. For more information about this decision, see Improving Stability by Reducing Usage of non-SDK Interfaces.

    Differentiate between SDK and non-SDK interfaces

    Generally speaking, public SDK interfaces are those ones found documented in the Android framework Package Index. Handling of non-SDK interfaces is an implementation detail that the API abstracts away, so these interfaces are subject to change without notice.

    To avoid crashes and unexpected behavior, apps should only use the officially documented parts of the classes in the SDK. This also means that you should not access methods or fields that are not listed in the SDK when you interact with a class via mechanisms such as reflection.

    Blacklists, greylists, and whitelists

    With each release of Android, additional non-SDK interfaces will be restricted. We know these restrictions can impact your release workflow, and we want to make sure you have the tools to detect usage of non-SDK interfaces, an opportunity to give us feedback, and time to plan and adjust to the new policies.

    To minimize the impact of non-SDK restrictions on your development workflow, the non-SDK interfaces are divided into lists that define how tightly their use is restricted, depending on which API level is being targeted. The following table describes each of these lists:

    List Description

    Blacklist Non-SDK interfaces that you cannot use regardless of your app's target API level. If your app attempts to access one of these interfaces, the system will throw an error.

    Greylist Non-SDK interfaces that you can use as long as they are not restricted for your app's target API level.

    Starting with Android 9 (API level 28), each API level has non-SDK interfaces that are restricted at that API level. Although a restricted greylist API can be accessed if your app targets a lower API level, if your app attempts to access a non-SDK interface that is restricted for your target API level, the system behaves as if the API is blacklisted.

    Note: In Android 9 (API level 28), the non-SDK interfaces from the non-restricted greylist were called the lightgrey list, and the non-SDK interfaces from the restricted greylist were called the darkgrey list.

    Whitelist Interfaces that can be freely used and are supported as part of the officially documented Android framework Package Index.

    While you can currently use some non-SDK interfaces that are part of the greylist (depending on your app's target API level), using any non-SDK method or field always carries a high risk of breaking your app. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK interfaces or other alternatives. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.

    Determine which list an interface belongs to

    The lists of non-SDK interfaces are built as part of the platform.

    For Android 9 (API level 28), this text file contains the list of greylisted APIs that are not restricted. The blacklist and restricted greylist are derived at build time. There is a build rule that generates the lists on AOSP. While the AOSP lists are not the same as the lists for Android 9, the overlap is fairly high. You can also generate the blacklist yourself by downloading AOSP and then running the following command:

    make hiddenapi-aosp-blacklist

    You can then find the file in the following location:

    out/target/common/obj/PACKAGING/hiddenapi-aosp-blacklist.txt

    Expected behavior when restricted non-SDK interfaces are accessed

    The following table describes the behavior that you can expect if your app attempts to access a non-SDK interface that is part of the blacklist.

    Means of access Result

    Dalvik instruction referencing a field NoSuchFieldError thrown

    Dalvik instruction referencing a method NoSuchMethodError thrown

    Reflection via Class.getDeclaredField() or Class.getField() NoSuchFieldException thrown

    Reflection via Class.getDeclaredMethod(), Class.getMethod() NoSuchMethodException thrown

    Reflection via Class.getDeclaredFields(), Class.getFields() Non-SDK members not in results

    Reflection via Class.getDeclaredMethods(), Class.getMethods() Non-SDK members not in results

    JNI via env->GetFieldID() NULL returned, NoSuchFieldError thrown

    JNI via env->GetMethodID() NULL returned, NoSuchMethodError thrown

    Test your app for non-SDK interfaces

    There are several methods that you can use to test for non-SDK interfaces in your app.

    Test using a debuggable app

    You can test for non-SDK interfaces by building and running a debuggable app on a device or emulator running Android 9 (API level 28) or higher. Make sure that the device or emulator that you are using matches the target API level of your app.

    While running through tests on your app, the system prints a log message if your app accesses certain non-SDK interfaces. You can inspect your app's log messages to find the following details:

    The declaring class, name, and type (in the format that is used by the Android runtime).

    The means of access: either linking, via reflection, or via JNI.

    Which list the non-SDK interface belongs to.

    You can use adb logcat to access these log messages, which appear under the PID of the running app. For example, an entry in the log might read as follows:

    Accessing hidden field Landroid/os/Message;->flags:I (light greylist, JNI)

    Test using the StrictMode API

    You can also test for non-SDK interfaces by using the StrictMode API. Use the detectNonSdkApiUsage method to enable this. After enabling the StrictMode API, you can receive a callback for each usage of a non-SDK interface by using a penaltyListener, where you can implement custom handling. The Violation object provided in the callback derives from Throwable, and the enclosed stack trace provides the context of the usage.

    Test using the veridex tool

    You can also run the veridex static analysis tool on your APK. The veridex tool scans the entire code base of the APK, including any third-party libraries, and reports any uses of non-SDK interfaces that it finds.

    Limitations of the veridex tool include the following:

    It can't detect invocations through JNI.

    It can detect only a subset of invocations through reflection.

    Its analysis for inactive code paths is limited to API level checks.

    Windows

    Native Windows binaries are not provided, but you can run the veridex tool on Windows by executing the Linux binaries using the Windows Subsystem for Linux (WSL). Before following the steps in this section, install the WSL and choose Ubuntu as your Linux distribution.

    After Ubuntu is installed, launch a Ubuntu terminal and then follow these steps:

    Download the veridex tool from the Android runtime prebuilts repository.

    Extract the contents of the appcompat.tar.gz file.

    In the extracted folder, locate the veridex-linux.zip file and unzip it.

    Navigate to the unzipped folder and then run the following command, where your-app.apk is the APK that you want to test:

    ./appcompat.sh --dex-file=your-app.apk

    macOS

    To run the veridex tool on macOS, follow these steps:

    Download the veridex tool from the Android runtime prebuilts repository.

    Extract the contents of the appcompat.tar.gz file.

    In the extracted folder, locate the veridex-mac.zip file and unzip it.

    Navigate to the unzipped folder and then run the following command, where your-app.apk is the APK that you want to test:

    ./appcompat.sh --dex-file=your-app.apk

    Linux

    To run the veridex tool on Linux, follow these steps:

    Download the veridex tool from the Android runtime prebuilts repository.

    Extract the contents of the appcompat.tar.gz file.

    In the extracted folder, locate the veridex-linux.zip file and unzip it.

    Navigate to the unzipped folder and then run the following command, where your-app.apk is the APK that you want to test:

    ./appcompat.sh --dex-file=your-app.apk

    Test using the Android Studio lint tool

    Whenever you build your app in Android Studio, the lint tool inspects your code for potential issues. If your app uses non-SDK interfaces, you may see build errors or warnings, depending on whether those interfaces are part of the blacklist or greylists.

    You can also run the lint tool from the command line or run inspections manually on a specific project, folder, or file.

    Test using the Play Console

    When you upload your app to a testing track in the Play Console, your app is automatically tested for potential issues and a pre-launch report is generated. If your app uses non-SDK interfaces, an error or warning displays in the pre-launch report, depending on whether those interfaces are part of the blacklist or greylists.

    For more information, see the Android Compatibility section in Use pre-launch reports to identify issues.

    Request a new public API

    If you cannot find an alternative to using a non-SDK interface for a feature in your app, you can create a feature request for a new public API to be added to the SDK.

    When creating a feature request, provide the following the following information:

    Which greylisted API(s) you are using currently, including the full descriptor seen in the Accessing hidden ...logcat message.

    Why you need to use these APIs, including details about the high-level feature that the API is necessary for, not just low level details.

    Why any related public SDK APIs are insufficient for your purposes.

    Any other alternatives you have tried and why these didn't work out.

    When you provide these details in your feature request, you increase the likelihood that a new public API will be granted.

    Other questions

    This section includes some answers to other questions that developers have frequently asked:

    General questions

    How can Google be sure they will capture the needs of all apps through the issuetracker?

    We created the initial lists for Android 9 (API level 28) through static analysis of apps that was supplemented using the following methods:

    manual testing of top Play and non-Play apps

    internal reports

    automatic data collection from internal users

    developer preview reports

    additional static analysis that was designed to conservatively include more false positives

    As we evaluate the lists for each new release, we take into account API usage as well as developer feedback through the issue tracker.

    How can I enable access to non-SDK interfaces?

    You can enable access to non-SDK interfaces on development devices by changing the API enforcement policy using the following adb commands:

    adb shell settings put global hidden_api_policy_pre_p_apps 1

    adb shell settings put global hidden_api_policy_p_apps 1

    To reset the API enforcement policy to the default settings, use the following commands:

    adb shell settings delete global hidden_api_policy_pre_p_apps

    adb shell settings delete global hidden_api_policy_p_apps

    These commands do not require a rooted device.

    You can set the integer in the API enforcement policy to one of the following values:

    0: Disable all detection of non-SDK interfaces. Using this setting disables all log messages for non-SDK interface usage and prevents you from testing your app using the StrictMode API. This setting is not recommended.

    1: Enable access to all non-SDK interfaces, but print log messages with warnings for any non-SDK interface usage. Using this setting also allows you to test your app using the StrictMode API.

    2: Disallow usage of non-SDK interfaces that belong to either the blacklist or the greylist and are restricted for your target API level.

    3: Disallow usage of non-SDK interfaces that belong to the blacklist, but allow usage of interfaces that belong to the greylist and are restricted for your target API level.

    Questions about non-SDK interface lists

    Where can I find the blacklist and greylists in the system image?

    They are encoded in the field and method access flag bits in platform dex files. There is no separate file in the system image that contains these lists.

    Are the blacklist and greylists the same on different OEM devices with the same Android versions?

    OEMs can add their own interfaces to the blacklist, but they cannot remove interfaces from the AOSP black or greylists. The CDD prevents such changes and CTS tests ensure that the Android Runtime is enforcing the list.

    Questions about the compatibility of related apps

    Is there any restriction on non-NDK interfaces in native code?

    The Android SDK includes Java interfaces. The platform started restricting access to non-NDK interfaces for native C/C++ code in Android 7 (API level 26). For more information, see Improving Stability with Private C/C++ Symbol Restrictions in Android N.

    Is there any plan to restrict dex2oat or DEX file manipulation?

    We don't have active plans to restrict access to the dex2oat binary, but we do not intend for the DEX file format to be stable or a public interface beyond the portions that are publicly specified in the Dalvik Executable format. We reserve the right to modify or eliminate dex2oat and the unspecified portions of the DEX format at any time. Also note that derived files produced by dex2oat such as ODEX (also known as OAT), VDEX, and CDEX are all unspecified formats.

    What if a crucial third-party SDK (for example, an obfuscator) cannot avoid using non-SDK interfaces, but does commit to maintain compatibility with future Android versions? Can Android waive its compatibility requirements in this case?

    We do not have plans to waive compatibility requirements on a per-SDK basis. If an SDK developer can currently only maintain compatibility by depending on interfaces in the greylists, they should begin planning a migration to SDK interfaces or other alternatives, and request a new public API whenever they cannot find an alternative to using a non-SDK interface.

    Do non-SDK interface restrictions apply to all apps including system and first-party apps, not just third-party apps?

    Yes, however, we exempt apps signed with the platform key, and we also have a package whitelist for some system image apps. Note that these exemptions only apply to apps that are part of the system image (or updated system image apps). The list is intended only for apps that build against the private platform APIs, rather than the SDK APIs (where LOCAL_PRIVATE_PLATFORM_APIS := true).

    Previous

    Target API Level

    Next

    Support 64-bit architectures

    Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

    Twitter Twitter

    Medium Medium

    LinkedIn LinkedIn

    Messenger Messenger

    More Android

    Android

    Enterprise

    Security

    Source

    Support

    Report platform bug

    Report documentation bug

    Community forums

    Google Play support

    Join user studies

    Documentation

    Developer guides

    Design guides

    API reference

    Samples

    Android Studio

    Google Developers

    Android

    Chrome

    Firebase

    Google Cloud Platform

    All products

    Privacy

    License

    Brand guidelines

    Get news and tips by email

    SUBSCRIBE

    LANGUAGE

  • Thanks for your reply plinkie. I've made a free lite version of my games which is the one I've submitted for publication so I'll see how that goes before I consider publishing the other 2 premium games I've made. Up until now it's been mostly plain sailing - I've found construct 3 really easy to use and overall excellent and exporting to android the signed APKs was also very easy to do.

  • When attempting to publish a game on Google Play (internal track) i receive this on the pre-launch report; "We've detected that your app is using unsupported APIs" (9 in total on the report) "The following APIs are greylisted and Google can't guarantee they will work on existing versions of android" "using APIs that aren't in the public android SDK can cause your apps to break" - my understanding is with each release of android, existing greylisted APIs move one step closer to becoming blacklisted. My games do not have any add-ons and yet I'm getting these messages of greylisted APIs. Maybe construct 3 need to update their systems to stop these messages appearing? Unless there's a way around this, my assumption is I can't publish games on Google Play currently? And even if I could it appears only a matter of time before greylisted APIs become blacklisted. And greylisted APIs mean there's a high risk of apps not working after the customer has paid to download them, which clearly isn't great. Any suggestions anyone?

  • Thanks plinkie, it looks like the 64-bit requirement isn't applicable to us then which is great news if that's the case!

  • Hi... Google Play are now saying all apps written in native code must provide a 64-bit version as well as a 32-bit version by no later than August 1st 2019. They are saying apps written in non-native code ,eg, Java and kotlin will not need code changes. Does anyone know if this 64-bit requirement is relevant to construct 3 users hoping to publish to Google Play? I assume construct 3 uses non-native code and is therefore not affected by the 64-bit requirement? Thanks in advance for any help!

  • 9 posts