Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

address violation of retrieving unsettable device #781

Merged

Conversation

wenxi-zeng
Copy link
Contributor

  • address violation of retrieving unsettable device
  • fix unit test

Copy link
Contributor

@prayansh prayansh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good. one comment about devices < API 18

* {@see https://developer.android.com/training/articles/user-data-ids}
*/
private static String getUniqueID() {
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR2) return null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason to return null if we are lower than API 18?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, the drm api is only available in 18+. so it's either we bump the min sdk to 18 or we do a check. and the getDeviceID method does a null check and returns random uuid as fallback.

@wenxi-zeng wenxi-zeng merged commit bf2f2c0 into master Jan 11, 2022
@wenxi-zeng wenxi-zeng deleted the wenxi/address-violation-of-retrieving-unsettable-device-id branch January 11, 2022 18:42
@chao2zhang
Copy link

👋 Hello @wenxi-zeng , do you happen to know which exact section of Google Play policy in https://support.google.com/googleplay/android-developer/answer/10144311 were we previously violating?

@wenxi-zeng
Copy link
Contributor Author

hey @chao2zhang it's under this section in the table.

Your app collects or links persistent device identifiers (e.g., IMEI, IMSI, SIM Serial #, etc.)

so IMEI, build serial, and android id are considered hardware ids, especially IMEI and build serial are unsettable ids. they are being restricted to use if SDK has min target to api 29 or above.

@chao2zhang
Copy link

chao2zhang commented Jan 14, 2022

Thank you. Looks like this is caught by this lint check .

@chao2zhang
Copy link

By the way, we noticed an app startup time regression of 100ms using a vanilla setup.

@andrew-polk
Copy link

I'm confused why this change didn't receive more fanfare.
One could easily consider this a breaking change, yet it didn't receive even a minor version number bump nor is it clear what the implications are from the changelog. Even this PR title is vague and misleading.

Our analytics have been relying on the context.device.id field to determine unique device counts, etc. This essentially invalidates all such data since the same device before and after this change will be seen as two different devices.
(If I've misunderstood something or there is some workaround I haven't considered, please let me know.)

I understand your hand was forced by the Android policy change, but this change should be communicated better.

@wenxi-zeng
Copy link
Contributor Author

hey @andrew-polk, sorry about the issue you're facing. but there is no workaround to map the two different ids because that's the exact thing google trying to address. we can't collect/store/map any ids that can trace to user's physical device or identity. it's either starting over with the new ids or keeping using the uncompliant id and get unpublished from the app store in August.
as for the versioning, we're sunsetting analytics-android. there will be no breaking/major changes. we only do patches. please consider to upgrade to analytics-kotlin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants