How Will I Build for Amazon (with plugins) in the Future?

Hi Rob and Vlad;

We are one of the several Corona developers that derive a VERY GOOD proportion of income from our apps on Amazon devices.

I know you guys are swamped with a lot to think of at the moment. But could you please also think about this question – it relates to whether, going forward, there will be any way to “build” with older versions of Corona. Here is the reason for my question:

  1. Last November (18 Nov, 2019), in this thread, “Paid Plugins from Corona support: Chartboost, AdColony” ( https://forums.coronalabs.com/topic/74770-paid-plugins-from-corona-support-chartboost-adcolony/? ), I pointed up an Amazon show-stopping problem. 

  2. The problem I described in detail was that, on the 64-Bit Corona Builds, we could not make an Amazon APK that included any of the most-used advertising plugins. When including any single plugin, our apps launched with an erroneous “Error” message related to “Google Play Store” – when none of these plugins had any relation to Google Play. That error message halted/crashed our Amazon apps - in testing.

  3. On 18 Nov, 2019, Rob Miracle’s advice was: “If you’re going to target Amazon, you probably should be using a build before 2019.3490. Amazon is still 32-bit and I don’t know when we will get 64-bit builds working for Amazon.  Rob”

  4. So, ever since that advice, the only way that our Amazon apps can be published and display any advertising is by building with a Corona Build version from May, 2019 (Corona Build #3476). We are doing this routinely now.

What do you guys think the situation on this will be when we get to offline builds? Will we be able to make Amazon builds with plugins? Or would we essentially be out of the Amazon app business because a key part of Amazon monetization would disappear?

Thanks for any light you can shed on this.

Steve

I do the same thing and it is very frustrating for sure!

I really hope they sort the dependencies out so Amazon is a viable build platform on latest builds.

Amazon is only 10% of revenue for me, but hey who throw’s away 10%?

Fingers crossed, but I think this might be a non-issue. I just did an Amazon build using 3575 and was able to successfully test it via Amazon’s Live App Testing. I am running the following ad networks:

  • AdColony
  • AppLovin’
  • Facebook Audience Network
  • Vungle

During my testing, I was served ads from AdColony and Vungle and was taken to the Amazon Appstore when I tapped on “Install”. I also was able to complete an IAP purchase successfully.

The one caveat is that Amazon’s compatibility test reported a minor issue : “Your APK includes a manifest declaration or an API invocation referring to Google in-app billing services.” It says that the app can be submitted to the Amazon Appstore, but fixing the issue is recommended.

I’m cautiously optimistic that things are OK as-is, and will only require a little bit of engineering attention to get back to 100%. That said, I’ll continue building with 3490 for as long as I can and be keeping a sharp eye on this. Between IAP and advertising, over of 50% of our app’s revenue comes from Amazon, so this is a critical issue for us.

–Appodeal 2.6.1 beta also works on Amazon.

When I use anything after 3490 I get a horrible Corona splash screen and then an error about Google libraries being included.

Unless build.settings is now being respected?

Hi;

SGS – the problem you are describing is the one that I described last November (the link to that forum post is iup above in the first post of mine to begin this thread.

But . . . following up on what colinmorgan and agramonte wrote, I’ve tested one of my apps that uses multiple plugins using the very recent Corona Build #3575. And I have good news like they did.

I was able to build the app and test it on an Amazon Fire device with NO immediate crash and with no warning about needing Google Play Store Assets (followed by an immediate shutdown).

The Plugins that build OK with Corona 3575 in this app are:

AdColony

StartApp

AppLovin

Flurry

Amazon iAP

Popup Social

Notifications

So this alleviates a big concern for me about future offline builds and Amazon.

As a side note, Chartboost is broken in a new show-stopping way with Corona Build 3575. If I strip out the other advertising plugins and simply invoke an “init” of the Chartboost plugin instance, my app crashes when the listener is being called back following the “init”. The app crashes without any message detailing why it crashed. The listener does not actually get any data – I can simply tell from a series of print statements that this is what is crashing the app.

Note that the exact same app with NO code changes and the same “Chartboost only” plugin setup DOES NOT CRASH at this point if the Amazon APK is built with Corona 3549 (last April version).

So there is something that worked OK with the Chartboost plugin in 3549 that is now completely broken with Corona 3575 – and it crashes the app.

Any thoughts from Rob or Vlad?

Thanks;

Steve

Quick followup on this: I just built for Amazon with 3579 and I’m still getting the “Google In-App Billing Detected” warning when I upload the .apk to Amazon’s Appstore.

In spite of this, I’m probably going to do a production release with the latest build now. Advertising and IAP appear to be working just fine, and, this way, if there is a problem I can quickly do another release built with 3490 before the system goes down.

If anyone has any thoughts, I’d be happy to hear them.

Vlad or Rob,

Any chance the “Google In-App Billing” issue is going to get any attention before the end of the month when the legacy builds that are “Amazon friendly” stop working?

As I said above, everything seems to work just find, but part of the warning from Amazon is that because they detect the Google billing API, they might limit the devices that can download the app. I get more than 300 downloads a day from the Amazon Appstore, and if Amazon stops letting my app be downloaded by Kindle users it’s going to do me real financial harm.

I’ll be doing an update next week with 3580, which I know still has this issue, but I could hold off a little while if I knew that there would be a daily build prior to the end of the month that would address the problem.

Alternately, if anyone has done an Amazon update using a 64-bit build and not seen a sudden drop off in downloads, hearing that would do a long way towards easing my mind.

Thank you,

Colin.

Hi Vlad and Rob;

I’m totally in agreement with Colin. And I’m extra worried that Amazon builds will be a low priority for you guys moving forward. This would GREATLY impact my business too!

Can anything be done soon (before the big transition) to have the Amazon builds come out clean (with Amazon) with no Google billing code?

Thanks and best;

Steve

I built for Amazon with 3577 with no issues or warnings and the build worked fine on my kindle test device.

Yes SGS. It is building fine locally for me too (3575).

The problem, as described by Colin, is that Amazon doesn’t like the inclusion of the Google code (see above) after the app is submitted for release in the Amazon Store.

Thanks;

Steve

Hmmm seems I cancelled the submission to change some screenshots.  Just submitted the update so let’s see what happens?

Quick followup on this: I just built for Amazon with 3579 and I’m still getting the “Google In-App Billing Detected” warning when I upload the .apk to Amazon’s Appstore.

In spite of this, I’m probably going to do a production release with the latest build now. Advertising and IAP appear to be working just fine, and, this way, if there is a problem I can quickly do another release built with 3490 before the system goes down.

If anyone has any thoughts, I’d be happy to hear them.

Vlad or Rob,

Any chance the “Google In-App Billing” issue is going to get any attention before the end of the month when the legacy builds that are “Amazon friendly” stop working?

As I said above, everything seems to work just find, but part of the warning from Amazon is that because they detect the Google billing API, they might limit the devices that can download the app. I get more than 300 downloads a day from the Amazon Appstore, and if Amazon stops letting my app be downloaded by Kindle users it’s going to do me real financial harm.

I’ll be doing an update next week with 3580, which I know still has this issue, but I could hold off a little while if I knew that there would be a daily build prior to the end of the month that would address the problem.

Alternately, if anyone has done an Amazon update using a 64-bit build and not seen a sudden drop off in downloads, hearing that would do a long way towards easing my mind.

Thank you,

Colin.

Hi Vlad and Rob;

I’m totally in agreement with Colin. And I’m extra worried that Amazon builds will be a low priority for you guys moving forward. This would GREATLY impact my business too!

Can anything be done soon (before the big transition) to have the Amazon builds come out clean (with Amazon) with no Google billing code?

Thanks and best;

Steve

I built for Amazon with 3577 with no issues or warnings and the build worked fine on my kindle test device.

Yes SGS. It is building fine locally for me too (3575).

The problem, as described by Colin, is that Amazon doesn’t like the inclusion of the Google code (see above) after the app is submitted for release in the Amazon Store.

Thanks;

Steve

Hmmm seems I cancelled the submission to change some screenshots.  Just submitted the update so let’s see what happens?

OK- I think I solved it:

It was actually something SGS said back in February about “build.settings being respected” that led me to really start monkeying with my build.settings, which I hadn’t really done up to this point because my build.settings have been working for Amazon builds for years now.

What I did was create an Amazon-specific build.settings file and start yanking things out of it until got a build that didn’t show up as having the Google Billing API when Amazon did their automatic checking. I ended up removing:

  • “plugin.google.iap.v3” from the plugins section*
  • “com.android.vending.BILLING” from usesPermissions
  • “com.android.vending.CHECK_LICENSE”, } from usesPermissions
  • "meta-data android:name=“com.google.android.gms.ads.APPLICATION_ID” from applicationChildElements

I don’t know for sure which one (or ones) of these made the difference, but I suspect it was “com.android.vending.BILLING”. I did a build where only “plugin.google.iap.v3” was removed and it still showed up as having the Google Billing API. My guess is that in the 32-bit-build days, Amazon builds ignored the “com.android.vending” lines from userPermissions. (This is, however, pure speculation.)

Anyway, I got an issue-free build with 3580, so I now feel pretty confident going forward that Amazon updates are going to be OK.

*Just to head off any questions, in my old build.settigns “plugin.google.iap.v3” was flagged with supportedPlatforms = { android=true, },

Last time I built an Amazon app I had to use a 32-bit build (3480) due to issues with the AdMob plugin.  Has anyone got it working with the 64-bit builds?

FYI @colinmorgan whenever I build for Amazon I have always commented these two parameters out of the build.settings, because I recall years ago they would cause an issue:

com.android.vending.BILLING

com.android.vending.CHECK_LICENSE