Another Google SDK update: com.google.android.play:core

Hello! I'm writing on behalf of my friend feryk, who cannot get his profile activated on the forum.

Feryk struggles with multiple games, which Google constantly rejects with message:
"We detected user data transmitted off device that you have not disclosed in your app’s Data safety form as user data collected."

- Applications does not collect or share any data
- Applications don't use any inApp objects or payment methods, nor GPG objects.
- feryk tried this with multiple versions of ctf, including last versio update (androidinapp295update)

- This issue is even with newly created games.

Could be there any other plugin, that causes this?
Is there any info about the rejected games I should share here?

Sure, here are a few examples (I can see one of the games uses GPG):

App1 - Rejected
Android Font Packer (FontPacker.mfx)
Android New Dialog Control v2 (AndroidDialog.mfx)
Android object (Android.mfx)
Multiple Touch (MultipleTouch.mfx)

App2 - Rejected
Android Font Packer (FontPacker.mfx)
Android object (Android.mfx)

App3 - Rejected
Android Font Packer (FontPacker.mfx)
Android Dialogs (AndroidDialogs.mfx)
Android object (Android.mfx)

App4 - Rejected
Android Font Packer (FontPacker.mfx)
Android object (Android.mfx)
GPG Connector (GPGConnect.mfx)
GPG Leadboard (GPGLeaderboard.mfx)

List and Ini they are fine.
Things that repeat:
I use Android Font Packer for Arial and Arial Black fonts.
I use the Open URL command in the Android object. Link to my game on Google Play.
Otherwise, every application is different.

Quote from Dobermann

There is a form to fill in the Google Console to say you don't collect data. This is what you are missing i believe. With the changes they made to the Google Console, i have no idea where to find this tab... Isn't there any warning message at top when you try to publish an app saying you need to fill a form or something like that?

Well obviously we know this (we read through the forum; we do not share any data and this information is disclosed in the form). It's just pain finding out from Google, what they want you to do

Although thanks for help.

Today they even sent (after more than a month) a following message (among other things):

Quote

We found the following data types sent off device that were not yet disclosed:
Android ID in APK/app bundle version ...

These said apps surely don't send any Android ID...

Quote from Fernando

To clarify, since a few months back, when using Android Object, there has been code that will be detected as you are asking for data, like email, device ID, and IMEI, even though you are not using it. The solution is to add a line in your policy to mention this.

From Olivier's suggestion, "This app may request access to the Device Or Other IDs shared for app functionality. "

_Note_ possibly this will happen with Android Plus, but never had any problem in the past.

also correlated to:

Post

RE: Another Google SDK update: com.google.android.play:core

Issue with Google Play Data Safety Policy Rejection

Hi everyone,

I compiled an Android app using Clickteam Fusion with the Android export module. In the Fusion settings, I pointed the JDK and SDK directories to those in Android Studio. My app does not collect any user data, so I did not request any permissions in the app.

I used API Level 34 with a target version of 14 and a minimum version of 5. The app compiled successfully, and Google Play Console did not flag any errors during the upload.…

dropsonteam

December 12, 2024 at 9:34 AM

Hello, okay, I see.
However, after a little update it looks like Font Packer is doing the same thing. It is quite frustrating stating, that we are sharing some data, even though we don't and I don't see, why we should do that.
And I understand Google throws a monkey wrench into the works with those "security adjustments".

Quote from Fernando

To clarify, since a few months back, when using Android Object, there has been code that will be detected as you are asking for data, like email, device ID, and IMEI, even though you are not using it. The solution is to add a line in your policy to mention this.

From Olivier's suggestion, "This app may request access to the Device Or Other IDs shared for app functionality. "

_Note_ possibly this will happen with Android Plus, but never had any problem in the past.

also correlated to:

Post

RE: Another Google SDK update: com.google.android.play:core

Issue with Google Play Data Safety Policy Rejection

Hi everyone,

I compiled an Android app using Clickteam Fusion with the Android export module. In the Fusion settings, I pointed the JDK and SDK directories to those in Android Studio. My app does not collect any user data, so I did not request any permissions in the app.

I used API Level 34 with a target version of 14 and a minimum version of 5. The app compiled successfully, and Google Play Console did not flag any errors during the upload.…

dropsonteam

December 12, 2024 at 9:34 AM

Hi. I have 15 apps on google play. All are rejected. As of 10/17/2024, everything was fine. If something has changed in the extensions and you've known about it for a few months, why not let others know? !!! Google wants me to flag what I send or collect. But my games don't collect, share or request any data. So how do I know what to mark? I would expect better support than just answer: mark something. I never thought that Android Font Packer sends Android ID data...etc.. I still don't know what exactly is being sent and where. But I have no choice. So I have to mark that I'm sending an ID, maybe for analysis, even if I'm actually lying. After a month of appeals, two games were successfully appealed. The updates went through without me having to declare anything. But it's frustrating. Evidently there is something or some library in the engine that also causes false alarms. I won't deal with it anymore. I'll just declare that I'm sending some ID. But it annoys me.
PS: Thx Lukaaash, that he wrote for me. Unfortunately, contacting someone is an almost superhuman task. But after 35 days my account was finally activated here on the forum, so ok.

Quote from Yves

As fas as I understand (correct me Fernando if I'm wrong), the objects and/or the runtime don't send any ID themselves. It seems that Google now automatically detects if Java code reads the ID (for example if the object has a Get ID expression) and if so it "thinks" the ID is going to be used/sent by the application, even if this code is never called. So it's an over-protection of Google, or even a bug.

In the build 296 we're trying to remove the concerned code that is not used in extensions at build time, for example the Get ID functions, but it's not very easy. In the meantime (and/or if we can't do that for any reason in the net build), then you need to activate the option that says you use the ID in Google's dashboard.

Yes, it is very likely. Just use any Android extension (for example, Android Font Packer, Android Dialog, Android Object, GPG, etc.). Even if I don't use any command that would require some data, google won't release the app. Some applications are released after a long appeal. For some, it says that they are sending an Android ID.

Quote from Olivier

Could you please tell us more about this? Did Google gave any explanation as to why they ended up approving some of your apps that they rejected in the first place?

Unfortunately, Google does not provide much detail. All applications are rejected with this:
"...We found an issue in the following area(s):
Device Or Other IDs Data Type - Device Or Other IDs (some common examples may include Advertising ID, Android ID, IMEI, BSSID, MAC address)..."

After the appeal, only this will answer:
"...We’re reaching out in response to your recent appeal regarding our Data safety section of our User Data policy and enforcement of your app. You received an email regarding a compliance issue with your app because:
Your app’s Data safety section contains discrepancies between your disclosure and app behavior...."
OR
"...There are discrepancies between your disclosure in the Data safety section and app behavior. For example, we found the following data types sent off device that were not yet disclosed: Device Or Other IDs Data Type - Device Or Other IDs (some common examples may include Advertising ID, Android ID, IMEI, BSSID, MAC address) in APK/app bundle version..."
(Android ID is marked)

They do not disclose details even upon repeated requests.

For Example. After 3 weeks of appeals and explaining that the app does not share or collect anything:
"...Thanks for your patience.
After further review, we’ve accepted your appeal and included details below about what additional steps you’ll need to take to get your app to appear on Google Play.
Action required: Submit your app..."

Quote from Olivier

Thank you for your detailed answer feryk. I am suspecting some sort of false positive on Google's part. Alas for the time being I have no news to share on Clickteam's ability to do what Yves mentioned above (code exclusion). But I would like to add what follows. If Google receives enough appeals, then maybe they will change their review procedures. Fusion developers aren't the only ones to be impacted.

It is possible. But if the developer has many applications that will be rejected repeatedly, it may happen that his applications will be permanently blocked, etc. It could be a mistake on Google's part, but maybe it will stay that way. Perhaps a solution would be to allocate all commands that can send IDs to a special extension. There would be no need to figure out how to delete unused code. We'll see, maybe with time he will figure out where the problem is. It may well have something to do with the launch of the Google play PC service, maybe they changed the test parameters, etc. Who knows, many questions, few answers.