Upload Mobile Activation Ping in onStart
Categories
(Firefox for Android Graveyard :: General, defect, P1)
Tracking
(firefox-esr60 wontfix, firefox-esr68 verified, firefox68 wontfix, firefox69 verified, firefox70 verified)
People
(Reporter: vlad.baicu, Assigned: vlad.baicu)
References
Details
(Whiteboard: [fennec68.1])
Attachments
(1 file)
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-esr68+
|
Details | Review |
Bug 1534451 added a non-trivial amount of background
computation during onCreate. This introduced regressions by tickling the balance of existing race conditions.
We're changing this by now uploading in onStart. Ideally we want to send this mobile activation ping at least once from every client at startup.
Assignee | ||
Comment 1•2 years ago
|
||
Bug 1534451 added a non-trivial amount of background computation during
onCreate. This introduced regressions by tickling the balance of existing
race conditions.
We're changing this by now uploading in onStart. Ideally we want to send
this mobile activation ping at least once from every client at startup. This change
should have minimal impact and keep the same consistency with the core ping.
Comment 2•2 years ago
|
||
status-firefox-esr68=affected because we'll want to uplift this fix to Fennec ESR 68.
Pushed by nalexander@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d1e08b5e6584 Upload Mobile activation ping in onStart. r=nalexander
Comment 4•2 years ago
|
||
bugherder |
Comment 5•1 year ago
|
||
Vlad, can you please request uplift for your fix to Fennec ESR 68.1 and Beta?
Assignee | ||
Comment 6•1 year ago
|
||
Comment on attachment 9085483 [details]
Bug 1573868 - Upload Mobile activation ping in onStart. r=nalexander
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration:
- User impact if declined: Bug 1534451 introduced a system addons regression. With this patch we aim to fix that issue.
- Fix Landed on Version:
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): We're delaying a bit the point at which we try to upload the activation ping in order to not interfere with other existing race conditions.
- String or UUID changes made by this patch:
Beta/Release Uplift Approval Request
- User impact if declined: Bug 1534451 introduced a system addons regression. With this patch we aim to fix that issue.
- Is this code covered by automated tests?: Unknown
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): We're delaying a bit the point at which we try to upload the activation ping in order to not interfere with other existing race conditions.
- String changes made/needed:
Assignee | ||
Updated•1 year ago
|
Comment 7•1 year ago
|
||
Comment on attachment 9085483 [details]
Bug 1573868 - Upload Mobile activation ping in onStart. r=nalexander
Approved for Fennec 68.1b8.
Comment 8•1 year ago
|
||
bugherderuplift |
![]() |
||
Comment 9•1 year ago
|
||
bugherderuplift |
Updated•1 year ago
|
Comment 10•1 year ago
|
||
Vlad, can you confirm what this change did?
I ran this comparison to the core ping: https://sql.telemetry.mozilla.org/queries/64358/source
And we're still seeing way more core pings and telemetry clients reporting core pings than activation.
Comment 11•1 year ago
|
||
A few questions on that analysis:
- What is the activation ping reporting as the channel? I see e.g. org.mozilla.firefox, and org.mozilla.firefox_beta (but no others). Are those release/beta?
- Did this change entail having every client send the activation ping at the beginning of every session? If so it doesn't look like it's even hit pre-release.
- Is this data being sent from nightly? What is the associated channel for that and ESR in the activation ping?
Assignee | ||
Comment 12•1 year ago
|
||
Hello, we only delayed the point in time where the upload takes place in order to avoid race conditions when the app starts.
I think it's intended to see a lot more core pings because those have been in place for quite some time and they are sent per session. The activation ping is currently implemented to be sent once per client. Once we have a succesful upload of the activation ping, we will no longer upload on further attempts.
On channel we are reporting the android package name which should allow us to determine what distribution it is.
Yes, we should be uploading from nightly as well, try 'org.mozilla.fennec_aurora'. I don't think we have a way to differentiate between release and esr for any pings as of this moment but I can look more into it.
Comment 13•1 year ago
|
||
Okay, it doesn't sound like there's any good way to confirm this from the data. Let's assume that this bug's result is working as intended.
Comment 14•1 year ago
|
||
Vlad, can you please provide the steps for verifying the fix? Thanks
Comment 15•1 year ago
|
||
Diana has received the infos for testing. Removing the ni.
Comment 16•1 year ago
|
||
Hi, I tried checking today the issue with https://sql.telemetry.mozilla.org/queries/63102/source#161803 but after running the query:
"select app_name, count(*) from moz-fx-data-shared-prod.mobile_live.activation_v1
where submission_timestamp > '2019-08-29' group by 1" there wasn't anything displayed.
As per my understanding a fresh install off the application or a clear data will trigger the activation ping.
I checked with a Sony Xperia Z5 (Android 7.0) on ESR Firefox Beta 68.1b8.
Comment 17•1 year ago
|
||
Hi,
Verified as fixed, with the correct query, on Firefox Nightly 70.0a1(2019-08-29), Firefox Beta 70.0b2/Firefox Beta 69, ESR Firefox Beta 68.1b8 with:
- Sony Xperia Z5 (Android 7.0)
- Google Pixel 3 XL (Android 9)
- Samsung Galaxy Note 9 (Android 8.1.0)
Updated•1 month ago
|
Description
•