segmentio / analytics-android

The hassle-free way to add analytics to your Android app.
https://segment.com/docs/sources/mobile/android/
MIT License
377 stars 214 forks source link

Do we need to upgrade integration SDKs? (ref: Device ID Collection Circumvents Google Play User Data Policy) #809

Closed csantarin closed 2 years ago

csantarin commented 2 years ago

From https://github.com/segmentio/analytics-android/issues/801#issuecomment-1152491861:

if you're using any device mode integration, you probably will see this warning even if you updated to 4.10.4. that's because the integration sdks internally uses an old version of analytics-android. a fix to that is underway.

@wenxi-zeng So, we're using Segment 4.9.3 and after reading this, it suggests we'll have to do the same for the rest of the integrations that we use. This is what we have:

Does that mean we'll have to also upgrade these integrations, especially the Amplitude one? According to the Gradle version conflict resolution strategy, AFAIK, it will choose the latest version of Segment, even when we don't upgrade.

wenxi-zeng commented 2 years ago

hey @csantarin, yes you're right. you'll need to do the same for the integrations. for amplitude, please upgrade to the latest 3.1.2. for appsflyer, since it's not an sdk maintained by segment, you'll have to raise an issue on their repo asking them to release a new version. the + sign only pulls the latest sdk at compile time. it won't change anything in a compiled/published sdk. but if you're using their source code, that's a different story.

wenxi-zeng commented 2 years ago

sorry, I missed your point. regarding conflict resolution, we also thought that gradle will choose the latest one, but we had customer getting warnings because of the integrations use the old analytics sdk. so we had to make new release for the integrations.

we have contacted Appsflyer team and requested them to make a new release. I checked the release date of the most recent Appsflyer was end of Jan, which is based on 4.10.2. it already addresses the google policy issue. so it should be ok to use.

csantarin commented 2 years ago

@wenxi-zeng Thanks for getting back to me!

but if you're using their source code, that's a different story.

Could you help me quickly understand what this is about? Is this referring to the usage of modules from either the Segment <> AppsFlyer integration or AppsFlyer itself?

the + sign only pulls the latest sdk at compile time. it won't change anything in a compiled/published sdk. [...] we have contacted Appsflyer team and requested them to make a new release. I checked the release date of the most recent Appsflyer was end of Jan, which is based on 4.10.2. it already addresses the google policy issue. so it should be ok to use.

OK, with Segment <> AppsFlyer using Segment 4.+, do we have to be concerned? AFAIK, it will make the integration defer to the latest Segment version. I understand it's always recommended that stay up to date, but in the off-chance that the Segment integration with AppsFlyer borked because we upgraded the integration SDK, can we still retain the existing Segment <> AppsFlyer version until we get that sorted out?

wenxi-zeng commented 2 years ago

hey @csantarin, don't worry about I said in the first comment. I misunderstood your question when I left the first comment. I got a confirmation from the AppsFlyer team. they will have a new release end of this month.

regarding to the + sign, you don't need to worry about on your side, because it pulls the latest version when the sdk is released and stays with that version in your usage. but you're right the + is discourage to use on your side to prevent sdk releases breaking your app.

csantarin commented 2 years ago

@wenxi-zeng Sounds good!

Last question: does upgrading Segment and the integration still guarantee we get the same data pre-upgrade? From the Segment dashboard, I've seen no difference so far. I looked up the official docs; there's no indication of any data loss there, too. Did notice that the context.device.id got longer, though. I suppose that's the result of using the new MediaDrm API?

wenxi-zeng commented 2 years ago

@csantarin yes. the device id would be different, since we're no longer collecting android id or any sort of id can trace to the physical device. but besides that, the data are all the same

csantarin commented 2 years ago

@wenxi-zeng got it. thanks!