Added a static broadcast receiver that will inform us as soon as possible of any installed packages.
Because mma methods are static, if LeanPlum is enabled, the event will be tracked even if the app was not running when the new package was installed
and as per LeanPlum's internal workings the event will be reported to the dashboard when the application resumes.
MozReview-Commit-ID: AGNsQn7LuCz
***
--HG--
extra : rebase_source : 3d40a9f85036c0495b110409bff86e56f8b7c465
Use SharedPreference to ensure we won't loose previous state if Fennec is killed, set as default, restarted.
The default browser status will only be set once, when the app is resumed, as it cannot change while the app is in foreground.
We will track "E_Changed_Default_To_Fennec" only if Fennec wasn't previously the default browser.
The method to track the event is safe to be called even before the mma init process is finished as LeanPlum postpones the track operation until it has actually been started.
Refactored MmaDelegate to not use a WeakReference for application context anymore as that should exist for the entire time the app is open, and only in that timeframe the MmaDelegate methods that use that context can be called.
MozReview-Commit-ID: JMJJclWj9fq
--HG--
extra : rebase_source : a6b3c6b097dfacb348a4fd0bbf054dd0c14b2d4a
Make mention of the new LeanPlum user attribute introduced as per Bug 1445799
MozReview-Commit-ID: 7jjRzh2wfe5
--HG--
extra : rebase_source : ad147e215e0e82d704c584677b7336a40997455e
This sketches the flavor dimensions. The important ones are
`audience` and `geckoBinaries`, which I think simplify the situation
greatly. Coupled with Bug 1417232 centralizing most everything in
`mobile/android/gradle.configure`, the Gradle configuration shouldn't
be so hard to evolve.
MozReview-Commit-ID: DILjVrnLA3F
--HG--
extra : rebase_source : a4ea96a49308f457a406716662d9b64d4ba749fe
extra : source : cec2b8828cc8800fa269d290ce38ea82c454b445
Historically, we used MOZ_NATIVE_DEVICES to proxy for Google Play
Services. (MOZ_NATIVE_DEVICES was the first GPS-consuming feature in
Fennec.) With Python moz.configure, we can easily add the real
top-level flag that distributions like F-Droid actually want, which is
to build without (non-free) Google Play Services entirely.
MozReview-Commit-ID: 7YJKw3G1lQA
--HG--
extra : rebase_source : 17a25d2a15868f3661248a06b9048741e5a1dca5
extra : intermediate-source : d4d42899e5cd4255df3bfb4332532936e42ebf43
extra : source : be888fa125dc1948fc073ed69aa8116f47e22877
Historically, we used MOZ_NATIVE_DEVICES to proxy for Google Play
Services. (MOZ_NATIVE_DEVICES was the first GPS-consuming feature in
Fennec.) With Python moz.configure, we can easily add the real
top-level flag that distributions like F-Droid actually want, which is
to build without (non-free) Google Play Services entirely.
MozReview-Commit-ID: 7YJKw3G1lQA
--HG--
extra : rebase_source : f599de01c63b873a95252d6b01128a6f069ff105
extra : intermediate-source : 060290b66b370137cfd3dbbac7c442ef107aaa68
extra : source : be888fa125dc1948fc073ed69aa8116f47e22877
Historically, we used MOZ_NATIVE_DEVICES to proxy for Google Play
Services. (MOZ_NATIVE_DEVICES was the first GPS-consuming feature in
Fennec.) With Python moz.configure, we can easily add the real
top-level flag that distributions like F-Droid actually want, which is
to build without (non-free) Google Play Services entirely.
MozReview-Commit-ID: 7YJKw3G1lQA
--HG--
extra : rebase_source : 04a8e4b89153a2a11e8a793e893a2e626cbc877a
Historically, we used MOZ_NATIVE_DEVICES to proxy for Google Play
Services. (MOZ_NATIVE_DEVICES was the first GPS-consuming feature in
Fennec.) With Python moz.configure, we can easily add the real
top-level flag that distributions like F-Droid actually want, which is
to build without (non-free) Google Play Services entirely.
MozReview-Commit-ID: 7YJKw3G1lQA
--HG--
extra : rebase_source : 1a6f7414c0b8108862701dca896befd815d2ac16
This sketches the flavor dimensions. The important ones are
`audience` and `geckoBinaries`, which I think simplify the situation
greatly. Coupled with Bug 1417232 centralizing most everything in
`mobile/android/gradle.configure`, the Gradle configuration shouldn't
be so hard to evolve.
MozReview-Commit-ID: DILjVrnLA3F
--HG--
extra : rebase_source : 2373eecc45e670ff7a5697f2e8095a8ea8fb5058
This sketches the flavor dimensions. The important ones are
`audience` and `geckoBinaries`, which I think simplify the situation
greatly. Coupled with Bug 1417232 centralizing most everything in
`mobile/android/gradle.configure`, the Gradle configuration shouldn't
be so hard to evolve.
MozReview-Commit-ID: DILjVrnLA3F
--HG--
extra : rebase_source : 311e1b18a2f0ad60b41d574f3c23aa160ecd56c0
Data review request comment:
1. What questions will you answer with this data?
We want to know when the user exit on-boarding. So we can start to A/B testing on other contextual hints. We don't want to overlap them.
2. Why does Mozilla need to answer these questions? Are there benefits for users?
We need this information to know if users had done on-boarding
3. What alternative methods did you consider to answer these questions? Why were they not sufficient?
I can't think of any.
4. Can current instrumentation answer these questions?
No
5. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories on the found on the Mozilla wiki.
I can't find one for Android
6. How long will this data be collected? Choose one of the following:
We want to permanently monitor this data. (Joe Cheng)
5. What populations will you measure?
All Fennec users
6. Which release channels?
All channels
7.Which countries?
All countries
8. Which locales?
All locales
9. Any other filters? Please describe in detail below.
No
10.Please provide a general description of how you will analyze this data.
We'd like to use Leanplum to cross-reference those events
11.Where do you intend to share the results of your analysis?
We'll use it internally
MozReview-Commit-ID: 2s7Hnc97dhp
--HG--
extra : rebase_source : 81736b5222490347fbc275fc8c8c06a4a2ee19c5
After speaking with liuche, we decided it'd be better to add a bit to determine
this rather than combining it with the isPocketEnabled field (which would be
loss of data) or cross-referencing the locale of the submitted event when
checking the Pocket value during telemetry analysis (which is hard to get right
and likely to get out of date).
MozReview-Commit-ID: JKFrdEsEbyp
--HG--
extra : rebase_source : bc20193ca29238cbde5361a840cbd367b492a346
Apparently, if you don't have whitespace above the bulleted list, it won't
format as a list.
MozReview-Commit-ID: LiLpSNScBxR
--HG--
extra : rebase_source : b3ec064a98a531aab5f38d7f4b3f338499010e97
The top sites menu button was removed in a previous iteration and long-click is
used to access the context menu now.
MozReview-Commit-ID: KzTg4Py8o8W
--HG--
extra : rebase_source : cc145006028b301b989ded16d15d3b12317be473
In the bug, we decided that it was okay to document this case because:
1) we didn't know the specific questions we were trying to answer
2) We were facing the 57 deadline
The alternative would be to change the behavior to perhaps the more intuitive
behavior where suggested sites will always be marked as "suggested" clicks but
note that there may be privacy concerns with that (in that there are a limited
number of suggested sites so we'd know the frequency that unique users might
visit the suggested sites).
MozReview-Commit-ID: GxQZzwoZ1nQ
--HG--
extra : rebase_source : 9c6697ef478a5ba08e1503d8360d1214419266fd
Remove all references to Build.SDK_INT comparing 14 and lower
MozReview-Commit-ID: JdAjYvQ6mfX
--HG--
extra : rebase_source : f6cae8af84c26f42dcc02c133e7bc702f1af61e6
Sylvestre Ledru
Petru Lingurar
Sebastian Kaspari
Nick Alexander
Brindusan Cristian
Ryan VanderMeulen
Margareta Eliza Balazs
Dorel Luca
Nevin Chen
maliu
Michael Comella
Chenxia Liu
Sebastian Hengst
Carsten "Tomcat" Book
friedger