braintree / braintree_android

Braintree SDK for Android
https://developer.paypal.com/braintree/docs/start/hello-client/android/v4
MIT License
402 stars 231 forks source link

com.paypal.android.sdk:data-collector not compliant with Play store policy due to device location collection #931

Open costafotjet opened 4 months ago

costafotjet commented 4 months ago

Braintree SDK Version

3.21.1

Environment

Production

Android Version & Device

No response

Braintree dependencies

com.braintreepayments.api:braintree:3.21.1

Describe the bug

We recently updated from 3.14.0 to 3.21.1. This might look similar to others, but the messaging is different from Google, I guess due to having used 3.14.0 for so long.

Violation User Data policy: Violation of User Data, Permissions and APIs that Access Sensitive Information Policies Details We have observed that your app is using an SDK that is designed to collect device location by default. This SDK can result in your app violating the prominent disclosure and consent and/or approved purpose requirements of Google Play’s User Data and Permissions and APIs that Access Sensitive Information policies. You are hereby requested to provide evidence of your compliance with the Prominent Disclosure and Consent requirements. Your app submissions will be rejected pending your action.

How to fix

Paypal Data Collector com.paypal.android.sdk:data-collector: Consider upgrading to version com.braintreepayments.api:data-collector:3.21.0 of the SDK.

The messaging in https://github.com/braintree/braintree_android/issues/783 is about persistent device identifiers, which is not the case here.

We previously dismissed this issue, after reading up on similar issues here, by upgrading from 3.14.0 to 3.21.1.

We also updated all unused tracks, apks by uploading new builds that only include com.braintreepayments.api:braintree:3.21.1.

The warning from Google is still there, referencing old builds that have been replaced in all tracks, and the deadline is moving closer. When we appealed, we were told the latest release, that definitely includes 3.21.1, is not compliant, which does not make sense.

Maybe Google is at fault here for not removing the warning yet? Looking at the diff here, the location lookup is removed between 3.14.0 and 3.21.1 - https://github.com/braintree/braintree_android/compare/3.14.0...3.21.1.

Can you confirm that 3.21.1 does not collect anything related to location?

Upgrading to v4+ is a major piece of work that is not feasible in a few days.

To reproduce

Release an app to the Play store using com.braintreepayments.api:braintree:3.21.1

Expected behavior

The app is not flagged by Google.

Screenshots

image

sshropshire commented 4 months ago

Hi @costafotjet thanks for using the Braintree SDK. We've gotten assurance from Google that version 3.21.1 resolves the issue in the past.

Also Google mentioned:

Please ask your merchants who believe they are only using newer/compliant versions to double-check all tracks (even private and unpublished tracks) and then to submit an appeal to Play directly.

Hopefully the above will help?

sshropshire commented 4 months ago

@costafotjet as an aside, would you be willing to share some of your experience upgrading to v4 of the SDK? We've received some feedback in the past about some of the migration being unclear, and we want to update our documentation to clear up any ambiguities. Any and all feedback (positive or negative) would be helpful 🙏.

costafotjet commented 4 months ago

Hello :)

I thought that was the problem at first. We have replaced all old builds, in every track (private, beta, alpha, you name it).

I can understand old builds with 3.14.0 being flagged by Google, as it is using some Kount methods that are querying location in some way? At least, that's what I got out of a look into the source code for 3.14.0.

But for 3.21.1 it all looks normal in my eyes and should be compliant.

When we sent an appeal, the latest release that includes 3.21.1 only, got mentioned in the email, which added even more confusion.

I have checked the build scan and the build itself is strictly using 3.21.1. My only option is to remove the SDK and try again, but that is not what we would like to do by any means.

We would love to do the migration. However, It is a complete rewrite and not something we could do safely in 3 days, hence why I am trying to find a temporary solution while the migration to v4 happens on a normal sprint that goes through testing etc.

sshropshire commented 4 months ago

@costafotjet got it yeah that's understood. It may be a Google issue we've seen a few inbounds related to this recently and even double checked with Google recently this month. They actually helped us modify 3.21.1 to reach compliance and it has been approved for other merchants in the past.

They basically told us "as long as the artifact hasn't changed, the SDK should be compliant." And we haven't made changes to the 3.21.1 artifact so theoretically it should be compliant. They are extremely vague on their process of scanning apps for compliance.

Our best option may be to file an appeal here. If there's anything specific to your app's submission they should be able to pinpoint the root cause.

costafotjet commented 4 months ago

I will include this issue and responses alongside other evidence that we are compliant.

Have a feeling the review/warning is stale, and now we are running around in circles trying to fix something that will probably go away on its own on deadline day.

Thanks for the prompt responses @sshropshire

ChetanPatelPlayBoxTV commented 4 months ago

@costafotjet I'm received email from google after using "com.braintreepayments.api:data-collector:3.21.0" . have you get any solution ? because today is on deadline day. @sshropshire Please update here

sarahkoop commented 4 months ago

Hi all - we reached out to Google recently to confirm that these versions of the SDK are still compliant see comment here.

sshropshire commented 4 months ago

Yes please update to 3.21.1 for v3 and 4.41.0 for v4 on all tracks (public and private) in the Google Play Console.

kmayoral commented 4 months ago

I'm just chiming in to echo everything @costafotjet has mentioned, our experience has been the same throughout.

Perhaps a minor difference in our experience was that when I initially made the update to our app to move to 3.21.1 I only submitted that change to closed beta and then production tracks (also we were upgrading from 3.17.2 as the non-compliant version).

I then received the rejection and only then moved to update the inactive tracks containing out of compliance builds, at which point I appealed and received the same messaging that my latest builds were still out of compliance.

We're currently past our deadline and waiting to hear back from support but I don't know what else to do besides trying to start the work involved in upgrading to v4.

Has anyone had success in resolving this issue by migrating to v4?

kmayoral commented 4 months ago

Additionally, do you have any insight @sarahkoop on what Google's system is looking for when marking an app as out of compliance? I only ask because I know that the change that resolved compliance issues was the removal of Kount in #742 but when I decompile my app using version 3.21.1 I can still see one string reference to kountMerchantId. I would hope that Google's system would not be looking at that instance to trigger a false positive but perhaps something similar to that is going on.

Here are some attached screenshots of the decompiled code and the single reference to it. Screenshot 2024-03-06 at 1 35 05 PM Screenshot 2024-03-06 at 1 34 45 PM

This also makes me wonder if this could be an issue for some of us due to some incorrectly set proguard settings....

kmayoral commented 4 months ago

Ah, I see, that decompiled code refers to KountConfiguration.java in the 3.x branch. I see that is still referenced in the Configuration class but is always set as null.

I don't know if that could be impacting Google's analysis but that is the only reference to to kount I can find in the build that Google is claiming is non-compliant.

Also, this rules out any proguard type issue since that class can't be removed due to still being referenced by Configuration.

Sergiohcp commented 4 months ago

Hi guys, we are having the same problem with our app, did anyone manage to solve it?

Kowshika-aspire commented 4 months ago

Hi everyone, we are facing same policy violation problem with our React native app. Used these sdks for braintree

Please help me to fix this issue.

costafotjet commented 4 months ago

We managed to fix the issue by migrating to v4 - com.braintreepayments.api:paypal:4.41.1.

The warning did not go away until:

For anyone trying com.braintreepayments.api:braintree:3.21.1:

Kowshika-aspire commented 4 months ago

We managed to fix the issue by migrating to v4 - com.braintreepayments.api:paypal:4.41.1.

The warning did not go away until:

  • All test tracks + production were replaced and pushed to 100% 1 day before the deadline.
  • Warning was still there after the deadline. So we uploaded another build to a test track and send it for review.
  • Then the warning got removed.

For anyone trying com.braintreepayments.api:braintree:3.21.1:

  • This is supposed to be a compliant version.
  • Google will not remove the warning before the deadline if you use this on everything besides production. Emails/appeals sent before to check if they would accept this version on production did not get anywhere constructive.
  • We never risked finding out on deadline day if v3.21.1 on all tracks + prod would have worked. Your mileage may vary.

@costafotjet Thanks for your reply.

So upgrading to com.braintreepayments.api:braintree:3.21.1 will fix this issue ?

vuphamdirox commented 4 months ago

Hi @costafotjet We are having the same issue. Could you confirm upgrading to com.braintreepayments.api:braintree:3.21.1 enough to fix this issue ? Thank you very much for your advise. Regards,

sshropshire commented 4 months ago

@Kowshika-aspire try updating to version 5.4.2 of DropIn.

@vuphamdirox updating to version 3.21.1 should be enough.

Also in Google Play, please make sure all tracks (production and test) are referencing the new build. This is the only explicit advice we've received from Google. It will not work unless all tracks reference your latest build with the up to date Braintree versions.

sshropshire commented 4 months ago

Also @kmayoral KountConfiguration.java is a data class maintained by Braintree. It's only used for JSON parsing, so it should be fine.

olessavluk commented 4 months ago

I am pretty sure all tracks were updated, even unpacking APK file marked by google shows it's using proper versions:

Packaged versions ![image](https://github.com/braintree/braintree_android/assets/1577804/6bf655e8-fe98-4f4d-aa25-30b53981ab3e)

We tried sending appeal for this exact build yesterday - no luck, appeal got rejected with exactly same reason. @costafotjet mentioned they got exactly same unproductive outcome from appealing:

Emails/appeals sent before to check if they would accept this version on production did not get anywhere constructive.

@sshropshire what would be your advice on appealing this? There are cleary something wrong with SDK or with google. Maybe you can provide "confirmation message" that @sarahkoop mentioned before to send them as argument?

kmayoral commented 4 months ago

@costafotjet 's comment seems to confirm (thank you by the way!) that the warning did not get resolved by updating to 3.21.1 and instead was only resolved after updating to the 4.x branch.

I'm several days past our deadline with multiple email threads with Google support underway while they investigate on their side but so far I can confirm that having all tracks set to a build that includes the 3.21.1 release is not resolving the issue even though Google has told me it should. That is why I went digging to find any unrelated references to Kount since my concern was they were just searching for that string within the build to raise a false positive for compliance flags.

I'll report back if I make any progress with Google on the 3.21.1. build but it sounds like I might need to do an emergency upgrade to 4.x based on @costafotjet 's latest comment. Thanks all for the help!!

gersonmdesouza commented 4 months ago

I'm facing the same issue, we are using com.braintreepayments.api:braintree:3.21.1 and Google is complaining about com.paypal.android.sdk:data-collector lib, they are asking me to update to com.braintreepayments.api:data-collector, is there a way to enforce com.braintreepayments.api:braintree to use com.braintreepayments.api:data-collector instead of com.paypal.android.sdk:data-collector?

Kowshika-aspire commented 4 months ago

@Kowshika-aspire try updating to version 5.4.2 of DropIn.

@vuphamdirox updating to version 3.21.1 should be enough.

Also in Google Play, please make sure all tracks (production and test) are referencing the new build. This is the only explicit advice we've received from Google. It will not work unless all tracks reference your latest build with the up to date Braintree versions.

@sshropshire Updated drop-in to 5.4.2. But still got policy violation issue,

This is our build.gradle file. Any suggestions please ?

Screenshot 2024-03-08 at 3 20 16 PM
vuphamdirox commented 4 months ago

@Kowshika-aspire try updating to version 5.4.2 of DropIn. @vuphamdirox updating to version 3.21.1 should be enough. Also in Google Play, please make sure all tracks (production and test) are referencing the new build. This is the only explicit advice we've received from Google. It will not work unless all tracks reference your latest build with the up to date Braintree versions.

@sshropshire Updated drop-in to 5.4.2. But still got policy violation issue,

This is our build.gradle file. Any suggestions please ?

Screenshot 2024-03-08 at 3 20 16 PM

@kmayoral https://github.com/braintree/braintree_android/issues/914#issuecomment-1934834555 From my understanding: I think we have to follow steps here to upload the build with upgraded to version 3.21.1 to all tracks ( internal/ alpha/beta testing and production) because Google play scan on all tracks

The email looks like potentially all apps and tracks have not been updated. Can you please try the following and confirm if the issue still exists:

Note: If you are seeing Google Play Store flag your APK after updating to the latest version of our SDK, please try following these steps:

Go to your Play Console Select the app Go to App bundle explorer Select the violating APK/app bundle's App version at the top right dropdown menu, and make a note of which releases they are under Go to the track with the violation. It will be one of these 4 pages: Internal / Closed / Open testing or Production Near the top right of the page, click Create new release. (You may need to click Manage track first) If the release with the violating APK is in a draft state, discard the release Add the new version of app bundles or APKs Make sure the non-compliant version of app bundles or APKs is under the Not included section of this release To save any changes you make to your release, select Save When you've finished preparing your release, select Review release, and then proceed to roll out the release to 100%. If the violating APK is released to multiple tracks, repeat steps 5-9 in each track

Kowshika-aspire commented 4 months ago

@vuphamdirox Thanks for your reply.

We still got this issue for latest bundle with drop-in 5.4.2.

Any suggestions ?

kmayoral commented 4 months ago

@vuphamdirox , thanks for your reply. Just as several others and myself have mentioned though, all tracks have been updated and we keep getting notified by Google that the version code bundle containing the 3.21.1 fix is still non-compliant.

BunnyBuddy commented 4 months ago

So far there's no solution to this issue? Are we supposed to sit back and relax while our apps are being rejected.

kmayoral commented 4 months ago

It seems that the only verified solution by @costafotjet was to update to the 4.x version of this repo. I can confirm that my bundles which contain the 3.21.1 release have been blocked and marked as non-compliant by Google (the package version code called out by google matches my 3.21.1 enabled release) so I'll be starting work on upgrading to 4.x tomorrow.

sshropshire commented 4 months ago

@BunnyBuddy @kmayoral we have reached out to Google as well and we're waiting to hear back. We were told this issue (due to a 3rd party dependency that we've since removed) was resolved. As soon as we receive more information we will report back here.

In the meantime, I would file an appeal in the Google Play console so that we can get more eyes on the issue.

kmayoral commented 4 months ago

Thank you @sshropshire! I've also filed several appeals and have been waiting for a response from a "specialist" support team on the Google side for five days now. They originally quoted a 24-48 hour turnaround on this investigation so I hope this means they're looking into something.

In the meantime, depending on internal decisions today, I will work on either upgrading to v4 or removing this library entirely to see if I can unblock our release process.

I'll update this thread if I hear anything more on the Google side, thank you!

sshropshire commented 4 months ago

Hey @kmayoral this may be a shot in the dark, but on your branch that references Braintree Android 3.x can you try adding this line to your build.gradle file and posting the build to Google Play?

implementation 'org.jfrog.cardinalcommerce.gradle:cardinalmobilesdk:2.2.7-5'

The 3.x version of the SDK is officially no longer supported, however I'm looking at the dependencies linked by the latest 3.x version, and I'm hoping the above line may elevate the Gradle dependency to a more compliant version if included.

kmayoral commented 4 months ago

Thanks for the suggestion @sshropshire. I tried adding that dependency into my app but it looks like it's not served from public maven repositories. I found a few threads on this github issue board related to specifying certain credentials and urls to be able to access but I feel like this might be going down the wrong path seeing how when I run gradle app:dependencies now I don't see that dependency referenced within my app or its depdendencies.

Ultimately, I think it might be related to Google's requirement that com.paypal.android.sdk:data-collector be updated to com.braintreepayments.api:data-collector package:

Paypal Data Collector com.paypal.android.sdk:data-collector: Consider upgrading to version com.braintreepayments.api:data-collector:3.21.0 of the SDK.

whereas I can see in my deps that the current version is com.paypal.android.sdk:data-collector:3.21.1

|    +--- com.braintreepayments.api:braintree:3.21.1
|    |    +--- androidx.appcompat:appcompat:1.2.0 -> 1.6.1 (*)
|    |    +--- com.braintreepayments.api:google-payment:3.3.1
|    |    +--- com.braintreepayments.api:core:3.21.1
|    |    |    \--- com.braintreepayments:browser-switch:1.2.0
|    |    |         +--- androidx.annotation:annotation:1.1.0 -> 1.6.0 (*)
|    |    |         +--- androidx.appcompat:appcompat:1.2.0 -> 1.6.1 (*)
|    |    |         \--- androidx.fragment:fragment:1.2.5 -> 1.6.1 (*)
|    |    \--- com.paypal.android.sdk:paypal-one-touch:3.21.1
|    |         +--- com.braintreepayments.api:core:3.21.1 (*)
|    |         \--- com.paypal.android.sdk:data-collector:3.21.1

If you have thoughts or think that it'd still be worthwhile to attempt the change you suggested, let me know, thanks again!

sshropshire commented 4 months ago

@kmayoral ok yes I would say add this as well for good measure:

implementation 'com.braintreepayments.api:data-collector:3.21.1'

This should force Gradle to pick the most up-to-date version. com.paypal.android.sdk:data-collector is a separate dependency in 3.x so they aren't interchangeable. It's one of the parts we cleaned up in v4.

We're looking to cover all bases here since we don't have explicit guidance from Google, but we did receive word that one of our merchants mentioned Cardinal SDK being cited as a possible compliance violation.

ncapdevi commented 4 months ago

@sshropshire I am having the same issue as others have noted above. I tried just now to add the data-collector implementation explicitly, and so have a gradle file containing the following:

    implementation "com.braintreepayments.api:braintree:3.21.1"
    implementation 'com.braintreepayments.api:data-collector:3.21.1'

I am still getting

SDK: Paypal Data Collector com.paypal.android.sdk:data-collector (consider upgrading to version com.braintreepayments.api:data-collector:3.21.0)

From the Play Store. I've reached out to them in the appeal process and they gave what seemed to be a bit of an automated response, that says to update to 3.21.0. I've also used gradle to analyze dependencies to see if anything else may have been including the sdk, but could not find it. Any other ideas?

kmayoral commented 4 months ago

Sorry for the lack of updates @sshropshire , I went ahead and started the work to migrate to v4 but have been running into issues.

We use braintree exclusively for PayPal vault support, but when I go to use v4 to handle my paypal flow, I don't see the callbacks being triggered. I can go to the browser, login to paypal and select my payment but when the window closes and I'm redirected back to my app, no PayPalListener callbacks trigger.

If I update my activity to set a launchMode of singleTask I am able to verify that the onNewIntent() method is called and contains a successful uriString of the format ${appPackage}.braintree://onetouch/v1/success?token=<token>&ba_token=<token2> but calling intent = newIntent in the onNewIntent callback doesn't appear to forward that on to any part of the braintree SDK as far as I can tell. Do I need to include any other braintree dependencies to get this to work? I'm just using the paypal dep currently. Thanks for any help and I'm happy to create a new issue for this if it helps!

kmayoral commented 4 months ago

Hmm, for some reason, I had to manually parse the intent myself via code like this to get it to register:

  fun onNewIntent(newIntent: Intent?) {
    payPalClient?.parseBrowserSwitchResult(activity, newIntent)?.let {
      payPalClient?.onBrowserSwitchResult(it) { nonce, error ->
        if (nonce != null) {
          onPayPalSuccess(nonce)
        } else if (error != null) {
          onPayPalFailure(error)
        }
      }
    }
  }

Not sure the details of why, but I'll go with it for now....

kmayoral commented 4 months ago

Well I spent the day updating from v3 to v4 which was quite a task but I was finally able to create new builds and attach them to all tracks and submit for review...only to get another rejection a few minutes ago.

My braintree deps look like this now:

|    |    |    +--- com.braintreepayments.api:card:4.41.0
|    |    |    |    +--- com.braintreepayments.api:braintree-core:4.41.0
|    |    |    |    |    +--- com.braintreepayments.api:browser-switch:2.6.1
|    |    |    |    |    |    +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10 -> 1.9.0 (*)
|    |    |    |    |    |    +--- androidx.annotation:annotation:1.2.0 -> 1.6.0 (*)
|    |    |    |    |    |    +--- androidx.appcompat:appcompat:1.3.1 -> 1.6.1 (*)
|    |    |    |    |    |    \--- androidx.browser:browser:1.5.0 (*)
|    |    |    |    |    +--- com.braintreepayments.api:shared-utils:4.41.0
|    |    |    |    |    |    +--- androidx.annotation:annotation:1.2.0 -> 1.6.0 (*)
|    |    |    |    |    |    \--- org.jetbrains.kotlin:kotlin-stdlib:1.7.10 -> 1.9.22 (*)
|    |    |    |    |    +--- androidx.appcompat:appcompat:1.3.1 -> 1.6.1 (*)
|    |    |    |    |    +--- androidx.work:work-runtime:2.7.0-alpha05 -> 2.8.1 (*)
|    |    |    |    |    +--- androidx.core:core-ktx:1.1.0 -> 1.10.1 (*)
|    |    |    |    |    +--- org.jetbrains.kotlin:kotlin-stdlib:1.7.10 -> 1.9.22 (*)
|    |    |    |    |    \--- androidx.room:room-runtime:2.2.6 -> 2.6.1 (*)
|    |    |    |    +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10 -> 1.9.0 (*)
|    |    |    |    \--- androidx.annotation:annotation:1.2.0 -> 1.6.0 (*)
|    |    |    +--- com.braintreepayments.api:paypal:4.41.0
|    |    |    |    +--- com.braintreepayments.api:braintree-core:4.41.0 (*)
|    |    |    |    +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10 -> 1.9.0 (*)
|    |    |    |    +--- androidx.appcompat:appcompat:1.3.1 -> 1.6.1 (*)
|    |    |    |    \--- com.braintreepayments.api:paypal-data-collector:4.41.0
|    |    |    |         +--- com.braintreepayments.api:braintree-core:4.41.0 (*)
|    |    |    |         +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10 -> 1.9.0 (*)
|    |    |    |         \--- androidx.annotation:annotation:1.2.0 -> 1.6.0 (*)

So I'm not sure why Google is still rejecting it, but I do see there is a paypal-data-collector (com.braintreepayments.api:paypal-data-collector:4.41.0), would that require any updates perhaps?

kmayoral commented 4 months ago

What's weird is that the rejection message references the bundle version for the release that is already in production, not the one I submitted for review. I'll resubmit in case there was some sort of blip or mistake on my part....

sshropshire commented 4 months ago

Thanks @kmayoral keep us posted. We're seeking more information from Google and they are starting to respond. We're asking for more specifics to help resolve these issues.

kmayoral commented 4 months ago

Thanks @sshropshire, we have multiple apps and they've all been rejected even after updating to v4 and having these dependencies set:

payment-braintree = { group = "com.braintreepayments.api", name = "card", version = "4.41.0" }
payment-braintreePaypal = { group = "com.braintreepayments.api", name = "paypal", version = "4.41.0" }

Those are the only dependencies we set and yet we're still getting errors that seem to be related to previous builds we submitted as the latest builds don't even feature the v3 classes they're referencing in their "how to fix" message.

Please let me know if you hear anything back from Google, thanks

kmayoral commented 4 months ago

Next build attempt started which adds data-collector to our dep list explicitly (even though our current implementation doesn't even reference it) like so:

payment-braintree = { group = "com.braintreepayments.api", name = "card", version = "4.41.0" }
payment-braintreeDataCollector = { group = "com.braintreepayments.api", name = "data-collector", version = "4.41.0" }
payment-braintreePaypal = { group = "com.braintreepayments.api", name = "paypal", version = "4.41.0" }

and

  implementation(libs.payment.braintree)
  implementation(libs.payment.braintreeDataCollector)
  implementation(libs.payment.braintreePaypal)

Producing this depedencies output, but I don't know how this won't be stripped out in the R8 step, but we'll see if this shot in the dark works....

 +--- com.braintreepayments.api:card:4.41.0
|    |    |    |    +--- com.braintreepayments.api:braintree-core:4.41.0
|    |    |    |    |    +--- com.braintreepayments.api:browser-switch:2.6.1
|    |    |    |    |    |    +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10 -> 1.9.0 (*)
|    |    |    |    |    |    +--- androidx.annotation:annotation:1.2.0 -> 1.6.0 (*)
|    |    |    |    |    |    +--- androidx.appcompat:appcompat:1.3.1 -> 1.6.1 (*)
|    |    |    |    |    |    \--- androidx.browser:browser:1.5.0 (*)
|    |    |    |    |    +--- com.braintreepayments.api:shared-utils:4.41.0
|    |    |    |    |    |    +--- androidx.annotation:annotation:1.2.0 -> 1.6.0 (*)
|    |    |    |    |    |    \--- org.jetbrains.kotlin:kotlin-stdlib:1.7.10 -> 1.9.22 (*)
|    |    |    |    |    +--- androidx.appcompat:appcompat:1.3.1 -> 1.6.1 (*)
|    |    |    |    |    +--- androidx.work:work-runtime:2.7.0-alpha05 -> 2.8.1 (*)
|    |    |    |    |    +--- androidx.core:core-ktx:1.1.0 -> 1.10.1 (*)
|    |    |    |    |    +--- org.jetbrains.kotlin:kotlin-stdlib:1.7.10 -> 1.9.22 (*)
|    |    |    |    |    \--- androidx.room:room-runtime:2.2.6 -> 2.6.1 (*)
|    |    |    |    +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10 -> 1.9.0 (*)
|    |    |    |    \--- androidx.annotation:annotation:1.2.0 -> 1.6.0 (*)
|    |    |    +--- com.braintreepayments.api:data-collector:4.41.0
|    |    |    |    +--- com.braintreepayments.api:braintree-core:4.41.0 (*)
|    |    |    |    +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10 -> 1.9.0 (*)
|    |    |    |    +--- androidx.annotation:annotation:1.2.0 -> 1.6.0 (*)
|    |    |    |    \--- com.braintreepayments.api:paypal-data-collector:4.41.0
|    |    |    |         +--- com.braintreepayments.api:braintree-core:4.41.0 (*)
|    |    |    |         +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10 -> 1.9.0 (*)
|    |    |    |         \--- androidx.annotation:annotation:1.2.0 -> 1.6.0 (*)
|    |    |    +--- com.braintreepayments.api:paypal:4.41.0
|    |    |    |    +--- com.braintreepayments.api:braintree-core:4.41.0 (*)
|    |    |    |    +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10 -> 1.9.0 (*)
|    |    |    |    +--- androidx.appcompat:appcompat:1.3.1 -> 1.6.1 (*)
|    |    |    |    \--- com.braintreepayments.api:paypal-data-collector:4.41.0 (*)
kmayoral commented 4 months ago

@sshropshire , reporting back that it seems that after a second attempt to get the same build from last night reviewed (which failed the first time around), it was accepted this time around. This was the build that updated to braintree v4 SDK.

I currently have a build in review that was submitted afterwards that contains the explicit data-collector dependency specified, and I'll report back if that somehow fails.

Ultimately though, it seems that the v3.21.1 release that Google claims will be treated as compliant is not being treated that way and only an upgrade to v4.x will resolve the issue at this time :(

Thanks all for all the help and I hope Google resolves the issue on their end for those developers who can't spend the resources to upgrade to v4 currently (it was a considerable undertaking and I'd be happy to provide some additional feedback in that regard @sshropshire , thanks!).

BunnyBuddy commented 4 months ago

Okay we finally got through.

First of all I had to update all the code utilizing Data Collector and Drop-In (because my code was fine uptill Drop-in 5.4.2 but not 6.13.0, had a lot of breaking changes) and changed the library version as follows.

implementation 'com.braintreepayments.api:drop-in:6.13.0'
implementation 'com.braintreepayments.api:data-collector:4.38.2'

Secondly, added this line our app's policy page "We only collect device data for Braintree (for the sole purpose of fraud detection)"

And also provided links to PayPal and Braintree's policy pages links there.

sshropshire commented 4 months ago

Hello all,

We're working with Google to find out what's causing the Google Play store compliance issue with the BT Android SDK.

The SDK does not collect privacy data directly, however we do have 3rd-party dependencies that collect data when needed to protect our merchants and their customers from fraudulent transactions. Third-party data collection and infrequent Play Store policy changes make it difficult to get explicit guidance from Google to pinpoint the exact cause of compliance issues.

Best Path Forward: Upgrade to v4

To achieve compliance, the best path forward will be to upgrade to the latest v4 version of the BT SDK. We understand that this takes effort and time. In the short-term, we're trying to find a workaround to help merchants who are stuck on v3. It's worth mentioning that Version 3 of our SDK is no longer supported and will not receive updates in the future.

Potential Workaround: Upgrade Cardinal Dependency

UPDATE: It is confirmed that updating Cardinal does not solve the issue.

~We did notice that v3 of our SDK is linked to an out-of-date version of the Cardinal SDK. The older Cardinal version linked by default may not have the necessary updates to achieve Google Play store compliance.~

~Theoretically, your app should be able to opt in to the newer version of Cardinal by placing the following in your app's build.gradle file:~

implementation 'org.jfrog.cardinalcommerce.gradle:cardinalmobilesdk:2.2.7-5'

~NOTE: We can't guarantee that the above works until we hear feedback from merchants stating that this helped resolve their Google Play compliance issue.~

Play Store Resubmissions

For either scenario, please make sure to update all tracks (release, testing, internal testing, etc.) when publishing a compliance update to Google Play. Google will reject apps if any track contains a build artifact that isn't compliant.

Google Play Store Appeal

As a last resort, we were informed that filing an appeal should help unblock merchants from making updates. When making an appeal in the Google Play store, make sure to mention the following:

  1. Indicate that you are aware of the compliance issue
  2. Indicate that you have updated to a compliant version of the SDK as requested
  3. Mention that you are working in earnest with the SDK provider to resolve compliance issues
  4. Request that you would like to be able to publish updates while working through compliance issues

Google has told us that the appeals team has often granted approvals for appeals in extreme scenarios like this. If granted an appeal, you should prioritize migrating to v4 of the BT SDK as soon as possible.

@all thank you for your patience as we work to resolve this matter.

kmayoral commented 4 months ago

Thanks @sshropshire , I think we all can relate to it being difficult to get guidance from Google regarding app store submissions.

Thanks for the summary and suggested workarounds, I'm sure that will help those who are still stuck dealing with this issue. I would only add a request to expand upon the process for performing the update of the Cardinal dependency. I was unable to get that to work as it seems that the cardinalmobilesdk is not served by any public maven repositories. I saw older issues on this board that described repo and credentials required to access this dependency but perhaps the latest details could be shared here as there seemed to be several out of date suggestions.

Thanks again for all the help and best of luck getting some clarification from Google on this issue.

alvaro-ritual commented 4 months ago

@kmayoral the credentials for said SDK have been shared here: https://github.com/braintree/braintree_android/issues/373. We are dealing with Google as well, will let you all know how it goes.

desxz commented 4 months ago

Hi @sshropshire, we have been getting this error for a while now and I can say that upgrading the cardinal package did not work. We updated the version of the cardinal package due to an error we received before, and although it appears as below in the dependency tree, we still continue to receive the error from Google.

| | +--- com.braintreepayments.api:three-d-secure:3.21.1 | | | +--- androidx.appcompat:appcompat:1.2.0 -> 1.4.1 (*) | | | --- org.jfrog.cardinalcommerce.gradle:cardinalmobilesdk:2.2.7-2 -> 2.2.7-5

alvaro-ritual commented 4 months ago

Hello all, I can also confirm that upgrading the cardinalmobilesdk did result in another rejection. Waiting for Google's reply.

sshropshire commented 4 months ago

@desxz @alvaro-ritual thanks for reporting this. We're still pressing Google for specifics.

Updating Cardinal seemed like something that could potentially fix at the time, though it appears the issue may be with the Magnes library. We'll report more information as it becomes available.

desxz commented 4 months ago

Hi folks, I don't know how but Play Store Resubmission with updating all tracks works for us today. Our app contains com.braintreepayments.api:drop-in:5.4.2 SDK (depends on com.braintreepayments.api:braintree:3.21.1).

ncapdevi commented 3 months ago

Any other updates on getting 3.2.1 approved?