READ_PHONE_STATE (Android) vs ads library (and other 3rd party ad code)

Solar2D Monetization (in-app purchases, ads, etc.)
#1

Long post, apologies in advance, complicated topic, also thanks in advance to any who take the time to read/consider it…

Does anyone have anything approaching an “authoritative” list of which ad networks do/do not require this permission? I mean REALLY require it, or REALLY can’t have it. Some clearly document one way or the other, many do not.

It seems quite a bit of a mess to me, and makes it far more difficult to implement an in-app mediation strategy across various networks (assuming that not all desired networks are yet supported as part of the ads library itself, which is frequently the case)

I do understand (fe, see docs on system.getInfo(“deviceID”)) why some networks might prefer to get the same AndroidID (without READ_PHONE_STATE) across all devices for tracking purposes.

Most common case for NOT having the permission seems when the ad network offers per-install (or other per-action) offers that need to be able to later cross-reference the installed-apps analytics - that say “I just ran for the first time on device XXYYZZ”, where XXYYZZ is that same AndroidID sent along with your affiliateID (aka appID) sent during the impression/click. Got it.

Less commonly needed if the ad network is just per-impression, in which case all they really need is your affiliateID (aka appID).

So, back to that wish for an “authoritative list”…

The entire ads library is documented as requiring this permission. So (presumably) for any ad network accessed through the ads library the answer must also be “YES, it’s needed”. (and perhaps other permissions, as specific to that provider - like inmobi, who seems to require every permission imaginable - but I’m not concerned about those here)

RevMob ?apparently? ?doesn’t? need it, but their docs are very sketchy. Their “Corona Sample” at GitHub doesn’t include it, but nor does it even require INTERNET, so it won’t even work AT ALL as written - can’t learn anything from that. Their “Sample With Storyboard” at least includes INTERNET permission, so will run as written and delivers ads, but does NOT include READ_PHONE_STATE, so who knows if that sample would actually properly track impressions so that you GET PAID? Their native-java Android sample DOES include READ_PHONE_STATE. What a hodge-podge.

Chartboost, at least, very clearly indicates that they MUST NOT have that permission set - they REQUIRE it not set so that AndroidID can be obtained. (so, Chartboost is one of those tricky ones to integrate with other providers that DO require the permission)

Vungle’s native Android API is documented as NOT requiring READ_PHONE_STATE (which makes sense since it’s a per-impression type network). But in Corona, it’s implemented via the ads library which is documented as DOES require the permission. So, the library requires it, but the plugin does not? wtf? What’s the true answer here? (ref: item 2 here: https://v.vungle.com/dev/android#title5)

AdMob’s native Android API is same situation as Vungle - The API itself is documented as NOT requiring the permission, yet implemented through ads library which DOES, so what’s the real deal?? (ref item 4 here: https://developers.google.com/mobile-ads-sdk/docs/)

And so, similarly, for other plugins – anyone have actual real-world implemented/tested evidence one way or the other for each? That is, you’ve implemented it, deployed it, and have evidence of getting paid/failing to get paid with/out the permission?

Wow, I’ve rambled on long enough, thanks for listening, and HUGE THANKS IN ADVANCE for any assistance documenting this further. :slight_smile:

#2

Hi @davebollinger,

I understand the frustration, but ultimately which permissions an ad provider requires is the responsibility of that ad provider to document. That being said, can you point me to the exact URL(s) where we (Corona Labs) state that any usage of the ads library requires READ_PHONE_STATE? I don’t think that’s the case, and I don’t recall if/when we stated that. If we did, it probably needs to be corrected.

Thanks,

Brent

#3

Hah, did you change the docs just before posting?!
Just kidding, but they have changed some time in relatively recent history.

There USED to be an entry for http://docs.coronalabs.com/api/library/ads/show.html (it’s dead now) and it had an “iOS” section, then an “Android” section which said “You must add the following permissions…” then showed the build.settings which did include READ_PHONE_STATE. This wasn’t for a particular plugin, this was for the ads library.

So, do your statements, and the now ABSENCE of that page (or any such page with similar content) means that the ads library ITSELF no longer has that requirement?

#4

Hi Dave,

Keen memory! … In fact, I did update the entire “ads” library documentation just a few days ago (the previous rendition was not very user-friendly and had various inconsistencies).

That being said, we *may* still require this permission for ads. In your tests, does this seem to be the case? Let me check into that and, if necessary, I’ll update the docs again on this note.

Brent

#5

Thanks Brent for the confirmation, at least I wasn’t imagining it all! :smiley:

I have very little to show in the form of RIGOROUS testing, just a lot of “ooh, that doesn’t seem right” moments, and plenty of similar posts here in the forums by others. Was hoping to solicit experience from other developers who might’ve already gone through all this.

Part of the issue for testing, is that sometimes analytics are delayed or corrupted or lost entirely, and by then you’ve assumed it’s your fault and so blindly change something, crossing fingers in the absence of rigorous documentation, and now you’ve got some other half-baked build running to try and “fix” it, forgetting to change a version number somewhere (if the ad network even supports it) thus muddling up your analytics even further, only to have a prior build’s antiquated analytics finally show up a week later and REALLY make a mess out of things. So which one was it that wasn’t counting impressions? Duh, i dunno? :smiley:

Of course, none of that scenario would be Corona’s “fault”, (rather the ad network and haphazard developer), BUT… if we could KNOW without doubt that we had certain settings correct, that would eliminate a tremendous amount of blind trial-and-error, that’s where proper/thorough documentation really matters.

Having a firm/proven statement confirmed/verified by Corona Engineering along these lines would be an awesome first step: (for example, tho of course word as you wish) “The ads library, in and of itself, DOES/DOES NOT require the READ_PHONE_STATE permission.” Then, assuming the answer is “DOES NOT”, you could go on to clarify… “Individual plugins may require additional permissions. You should consult the documentation for the init() method of a particular plugin to determine what permissions it requires.” Something along those lines?

In a perfect world, I could further hope for (but don’t realistically expect)…

Be rigorous with your partners if documenting their own plugins:

  1. If a permission is REQUIRED, then it MUST be listed as such. And we all know the English defintion of “REQUIRED”, right? It does not mean “optional”.
    [[and, conversely, 1b) any permission required to be ABSENT in order for the plugin to function properly, must be indicated as such – READ_PHONE_STATE being the main “gotcha” for this one]]
  2. If a permission is NOT REQUIRED, but only “optional” or “recommended” (like locational stuff often is) then the docs MUST clearly indicate so. (perhaps append such a comment on that line of the build.settings sample)
  3. Any permission which is not strictly required/forbidden, nor even “optional/recommended” should NOT be present in those docs in any form, so that we may assume from it’s absence that it is exempt from concern as regards this particular plugin.

Thanks,
Dave

#6

Hi Dave,

I’m going to bring this before the entire team next week and see how we can improve this process. I agree, users should not need to hunt around for which permissions are required and which aren’t, or which are optional. Ultimately, we can’t control which permissions are required for 3rd-party plugins, but if we document these plugins, we should cite the proper permissions.

Brent

#7

Hi @davebollinger,

I understand the frustration, but ultimately which permissions an ad provider requires is the responsibility of that ad provider to document. That being said, can you point me to the exact URL(s) where we (Corona Labs) state that any usage of the ads library requires READ_PHONE_STATE? I don’t think that’s the case, and I don’t recall if/when we stated that. If we did, it probably needs to be corrected.

Thanks,

Brent

#8

Hah, did you change the docs just before posting?!
Just kidding, but they have changed some time in relatively recent history.

There USED to be an entry for http://docs.coronalabs.com/api/library/ads/show.html (it’s dead now) and it had an “iOS” section, then an “Android” section which said “You must add the following permissions…” then showed the build.settings which did include READ_PHONE_STATE. This wasn’t for a particular plugin, this was for the ads library.

So, do your statements, and the now ABSENCE of that page (or any such page with similar content) means that the ads library ITSELF no longer has that requirement?

#9

Hi Dave,

Keen memory! … In fact, I did update the entire “ads” library documentation just a few days ago (the previous rendition was not very user-friendly and had various inconsistencies).

That being said, we *may* still require this permission for ads. In your tests, does this seem to be the case? Let me check into that and, if necessary, I’ll update the docs again on this note.

Brent

#10

Thanks Brent for the confirmation, at least I wasn’t imagining it all! :smiley:

I have very little to show in the form of RIGOROUS testing, just a lot of “ooh, that doesn’t seem right” moments, and plenty of similar posts here in the forums by others. Was hoping to solicit experience from other developers who might’ve already gone through all this.

Part of the issue for testing, is that sometimes analytics are delayed or corrupted or lost entirely, and by then you’ve assumed it’s your fault and so blindly change something, crossing fingers in the absence of rigorous documentation, and now you’ve got some other half-baked build running to try and “fix” it, forgetting to change a version number somewhere (if the ad network even supports it) thus muddling up your analytics even further, only to have a prior build’s antiquated analytics finally show up a week later and REALLY make a mess out of things. So which one was it that wasn’t counting impressions? Duh, i dunno? :smiley:

Of course, none of that scenario would be Corona’s “fault”, (rather the ad network and haphazard developer), BUT… if we could KNOW without doubt that we had certain settings correct, that would eliminate a tremendous amount of blind trial-and-error, that’s where proper/thorough documentation really matters.

Having a firm/proven statement confirmed/verified by Corona Engineering along these lines would be an awesome first step: (for example, tho of course word as you wish) “The ads library, in and of itself, DOES/DOES NOT require the READ_PHONE_STATE permission.” Then, assuming the answer is “DOES NOT”, you could go on to clarify… “Individual plugins may require additional permissions. You should consult the documentation for the init() method of a particular plugin to determine what permissions it requires.” Something along those lines?

In a perfect world, I could further hope for (but don’t realistically expect)…

Be rigorous with your partners if documenting their own plugins:

  1. If a permission is REQUIRED, then it MUST be listed as such. And we all know the English defintion of “REQUIRED”, right? It does not mean “optional”.
    [[and, conversely, 1b) any permission required to be ABSENT in order for the plugin to function properly, must be indicated as such – READ_PHONE_STATE being the main “gotcha” for this one]]
  2. If a permission is NOT REQUIRED, but only “optional” or “recommended” (like locational stuff often is) then the docs MUST clearly indicate so. (perhaps append such a comment on that line of the build.settings sample)
  3. Any permission which is not strictly required/forbidden, nor even “optional/recommended” should NOT be present in those docs in any form, so that we may assume from it’s absence that it is exempt from concern as regards this particular plugin.

Thanks,
Dave

#11

Hi Dave,

I’m going to bring this before the entire team next week and see how we can improve this process. I agree, users should not need to hunt around for which permissions are required and which aren’t, or which are optional. Ultimately, we can’t control which permissions are required for 3rd-party plugins, but if we document these plugins, we should cite the proper permissions.

Brent