Skip to content

[Diagnostics] Add play_store_version and play_services_version to all google events#2269

Merged
tonidero merged 3 commits into
mainfrom
diagnostics-add-play-store-services-versions
Mar 19, 2025
Merged

[Diagnostics] Add play_store_version and play_services_version to all google events#2269
tonidero merged 3 commits into
mainfrom
diagnostics-add-play-store-services-versions

Conversation

@tonidero

Copy link
Copy Markdown
Contributor

Description

This adds play_store_version and play_services_version to all google events.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Originally, I was planning to also add the billing_client_version as was in the doc, but I don't think we can get the version at runtime that I could figure out... We could hardcode it somewhere, but then, it basically means we already have the billing client version from the sdk version and we can obtain this info in the backend/DW.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Just mentioning that we could quite easily create a BuildConfig field set to libs.versions.billing.get(). That doesn't require any more hardcoding than we currently do (i.e. specifying the version in libs.versions.toml). But you're right that we can also infer this info from the SDK version.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Hmm that's a good point... But still seems like duplicated info... If we could figure out if the version didn't match at runtime (like for example if there was a bump because a dev was using a newer version of the billing client separately). But I think this way we can just have this information in the DW and even join if we need a view with this information.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Yea you're right. Btw the billing library leaves a billing.properties file in the final APK with the version that's being used. We might be able to read that? 👀
image

Something we could look into.

@tonidero tonidero marked this pull request as ready for review March 18, 2025 16:18
@tonidero tonidero requested a review from a team March 18, 2025 16:18
@emerge-tools

emerge-tools Bot commented Mar 18, 2025

Copy link
Copy Markdown

📸 Snapshot Test

14 modified, 378 unchanged

Name Added Removed Modified Renamed Unchanged Errored Approval
TestPurchasesUIAndroidCompatibility
com.revenuecat.testpurchasesuiandroidcompatibility
0 0 14 0 250 0 ⏳ Needs approval
TestPurchasesUIAndroidCompatibility Paparazzi
com.revenuecat.testpurchasesuiandroidcompatibility.paparazzi
0 0 0 0 128 0 N/A

🛸 Powered by Emerge Tools

@codecov

codecov Bot commented Mar 18, 2025

Copy link
Copy Markdown

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.31%. Comparing base (fb33fa4) to head (53fa52f).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2269      +/-   ##
==========================================
+ Coverage   80.30%   80.31%   +0.01%     
==========================================
  Files         278      278              
  Lines        9483     9489       +6     
  Branches     1336     1337       +1     
==========================================
+ Hits         7615     7621       +6     
  Misses       1308     1308              
  Partials      560      560              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ajpallares ajpallares left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks good! Just a small nit that you can totally ignore 😄

@JayShortway JayShortway left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This is gonna be very valuable! Just the concern on VisibleForTesting.

Comment on lines 263 to 264

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Is VisibleForTesting needed? I don't see trackEvent being used in tests. I would prefer to test a class' observable behavior, instead of opening up private methods for tests.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Unfortunately, it is currently used in some tests... For example:

.

We could totally refactor this to avoid making this internal, but didn't want to add further refactors in an unrelated PR. I just added this annotation because I noticed this was only used externally in tests and seemed easy to confuse with the other new trackEvent method.

Can do this change in a follow-up PR though.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Oh right, I see. Maybe the other trackEvent method, taking a DiagnosticsEntryName, has more "right" to be internal than this one, as this one requires the caller to know the appSessionID.

Not something we need to address in this PR indeed.

Base automatically changed from diagnostics-add-event-id-app-session-id to main March 19, 2025 09:43
@tonidero tonidero force-pushed the diagnostics-add-play-store-services-versions branch from 7044c5d to 3682cd4 Compare March 19, 2025 09:48
Comment on lines 263 to 264

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Oh right, I see. Maybe the other trackEvent method, taking a DiagnosticsEntryName, has more "right" to be internal than this one, as this one requires the caller to know the appSessionID.

Not something we need to address in this PR indeed.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Yea you're right. Btw the billing library leaves a billing.properties file in the final APK with the version that's being used. We might be able to read that? 👀
image

Something we could look into.

@tonidero tonidero merged commit b4e564c into main Mar 19, 2025
@tonidero tonidero deleted the diagnostics-add-play-store-services-versions branch March 19, 2025 10:31
This was referenced Mar 19, 2025
vegaro pushed a commit that referenced this pull request Mar 19, 2025
**This is an automatic release.**

## RevenueCatUI SDK
### 🐞 Bugfixes
* Fix landscape mode in Paywalls v1 Template 3 (#2265) via Josh Holtz
(@joshdholtz)
### Customer Center
#### ✨ New Features
* feat: Introduce `CustomerCenterView` for hybrid usage (#2170) via
Cesar de la Vega (@vegaro)
* Add `onManagementOptionSelected` to `CustomerCenterListener` (#2270)
via Cesar de la Vega (@vegaro)
### Paywallv2
#### 🐞 Bugfixes
* [Paywalls V2] Ignores missing font alias if it's blank. (#2271) via
JayShortway (@JayShortway)
* [Paywalls V2] Fixes badges not being overriden (#2266) via JayShortway
(@JayShortway)

### 🔄 Other Changes
* [Diagnostics] Add play_store_version and play_services_version to all
google events (#2269) via Toni Rico (@tonidero)
* [Diagnostics] Add `id` and `app_session_id` to events (#2268) via Toni
Rico (@tonidero)
* Uploads Paparazzi screenshots to Emerge. (#2232) via JayShortway
(@JayShortway)

Co-authored-by: revenuecat-ops <ops@revenuecat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants