Fix Lollipop crashes because of android.content.res.ColorStateList.addFirstIfMissing()
The default app theme will be applied for the material Date/Time pickers on
API 21 and API 22. After this, on API >=23 they will be Photon themed.
Differential Revision: https://phabricator.services.mozilla.com/D4464
--HG--
extra : moz-landing-system : lando
Fix running robocop tests on debug builds.
This patch fixes multidex issues when running robocop on debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D3422
--HG--
extra : moz-landing-system : lando
Multidex will now be enabled for all builds, not just for the _local_ ones.
Also added the 'ads-identifier' library needed for the builds with the
MOZ_INSTALL_TRACKING flag case in which the dex limit would be reached.
MozReview-Commit-ID: FRTXBD9Kc6T
--HG--
extra : rebase_source : c73a0a48d355edbe2080b14ceeb2f99609a45d7c
On Api >=21 the Material DatePicker will have applied a Photon style.
Below Api 21 DatePicker will still be using spinners.
MozReview-Commit-ID: LuWP6C1o4Ej
--HG--
extra : rebase_source : 91eccfdeb0c4f17e9f0616fa25463d1b5558009a
On Api >=21 the Material TimePicker will have applied a Photon style.
Below Api 21 TimePicker will still be using spinners.
MozReview-Commit-ID: 2jZLPGCx4rI
--HG--
extra : rebase_source : a57376bf59077b6d64bcca8ba704ca1b6324383e
We're planning on enabling block autoplay on desktop by default, so in order to
be consistent across platforms, we think we should also enable it on mobile by
default.
The change here makes us allow autoplay in tabs which have had user
interaction, rather than the legacy block autoplay implementation which
"blessed" media elements which had certain functions called in a user generated
event handler.
Current plan is to enable this on Nightly only (desktop & mobile) and solicit
feedback and then decide on whether to let it ride the trains.
MozReview-Commit-ID: IkusfUOrcgO
--HG--
extra : rebase_source : 0c0a8f80d3670fffe66540f66954eaa980a42e74
Refactored the previous test which verified if a Service was started with the
right Intent to now check if JobScheduler has the right Job enqueued with the
right work Intent.
MozReview-Commit-ID: G46GbjVVkqR
--HG--
extra : rebase_source : 4d9f030ed37767c02a27aa291f2c0338afd0619a
This tests verified if a Service was started or not. After the IntentServices
migration to JobIntentService this checks would not work anymore.
To keep the same test logic they will now check if JobScheduler has any
scheduled jobs.
Removed testStartIfReadyDoesNotRunTwiceInSuccession() because JobScheduler
already guarantees no two identical jobs can be scheduled in parallel.
MozReview-Commit-ID: JZ2XMecjsXq
--HG--
extra : rebase_source : 9d90e226adc15763c6e85842d5f896e671433e3a
Also made broadcasts involving Stumbler explicit.
MozReview-Commit-ID: 7CK2Cr2JqX0
--HG--
extra : amend_source : 4a7de557ad76f6cb2a0dcad5419ec2b37ca89e05
Moved the logic ouf of MediaControlService to a new singleton GeckoMediaControlAgent,
which delegates all media-related actions.Currently, MediaControlService is used
for the foreground notification and to retrieve actions from the notification
pending intents. Removed redundant test cases.
MozReview-Commit-ID: KukAmpnn33S
--HG--
rename : mobile/android/app/src/test/java/org/mozilla/gecko/media/TestMediaControlService.java => mobile/android/app/src/test/java/org/mozilla/gecko/media/TestGeckoMediaControlAgent.java
extra : amend_source : 251b7821f4ddefcf852480de72ca1004cbd261bf
Updated google play services version as part of work of the Oreo migration and removed unused libraries from gradle.
MozReview-Commit-ID: BKCWs938k3q
--HG--
extra : rebase_source : 2e9ad83904276607f27974206bd3ad0ba2879279
This patch also:
Resolves missing resources and api changes
- LeanplumActionBarActivity was removed because Support Library 26 deprecated
ActionBarActivity. Class was already not in use.
- CustomTabsService added two new methods which we need to override.
Tested to make sure that previous functionality was maintained but with the
addition of the two new methods maybe that feature could be improved.
- For checking layout direction we'll use our own new method from ViewUtil
which mimics what the now restricted method from the support library would do.
- Upgraded to use AppCompatResources#getDrawable(..) in place
of the now restricted AppCompatDrawableManager.get().getDrawable(..).
Resolves obscure leaks and crashes after the upgrade
- LoaderManager.destroyLoader(..) was added before the existing call to
LoaderManager.restartLoader(..) to prevent potential Cursor leaks
- Disable website suggestions depending on the address bar inputs when running
in automation to avoid Robocop tests failing (they were entering serially maybe
100 characters in <5 ms which created around that many new Threads,
operation that could cause the Executor to throw a RejectedExecutionException)
At the moment this functionality is not covered by tests anyway and it was the
only fix I could find that would not involve changing the whole implemenation
for address bar suggestions, implementation which in the real world works ok.
MozReview-Commit-ID: 2fX1SBHiSh0
--HG--
extra : amend_source : edb6c5853cdcea5ad50a7cf680f2214fdc176cb2
Use the exclusive VFS on unix systems, so that:
1. we can avoid the memory mapped -shm files in wal mode
2. we gain more compatibility with nfs shares
3. we gain some protection from third parties touching open dbs
On the other side it won't be possible anymore to use an open database from a
different process (like the Sqlite command line), for which we provide an hidden
pref: storage.multiProcessAccess.enabled
Differential Revision: https://phabricator.services.mozilla.com/D1964
--HG--
extra : moz-landing-system : lando
Created LeanPlumVariables to allow LeanPlum overwriting the values used for
populating the OnBoarding screens. By simply adding the @Variable annotation
to it's fields, on the first run of the app, they will appear in "LeanPlum
dashboard - Variables" and will allow overwriting for future runs.
The OnBoarding process will now try to use LeanPlum values if possible.
Because connecting to LeanPlum and downloading the Variables might take
a few seconds we use a delay of up to 3 seconds until starting to show
the Onboarding screens.
The default values will still be used if:
- if the LP experiment is not available
- if no internet connection
- if more than 3 seconds have passed and LP didn't finish it's download
Added two new events that could be tracked to Leanplum
MmaDelegate.ONBOARDING_DEFAULT_VALUES and MmaDelegate.ONBOARDING_REMOTE_VALUES
to inform if showing the Onboarding with server values was possible or not.
Because of the 3 seconds delay until showing the Onboarding panels leaking the
could be possible. Used WeakReferences for both the Activity in
OnboardingHelper and the OnboardingHelper in MmaLeanplumImp to avoid it.
MozReview-Commit-ID: H30e9Ng7jrM
--HG--
extra : rebase_source : e403b8010005aa82f8b6440586c533ce99952f9f
When it's false we also disable collecting events completely, in case the
reason we're disabling it is due to storage issues.
GeckoView doesn't presently support Events, so the 'event' ping is disabled by
default for that platform.
MozReview-Commit-ID: 9eKAtRiuER0
--HG--
extra : rebase_source : 71b3c9ff802420ff21941656c3d848c6d320578d
In case we change our thinking on launching of downloaded files and start using
content:// URIs for that case as well, we already allow our FileProvider to
generate URIs for the whole file system using <root-path>. This is because users
can in principle move our download directory to an arbitrary location on the
file system as long as it is accessible to Firefox. However not all of these
locations (e.g. on a removable SD card) can be specified through the other
methods of specifying available files for a FileProvider, so only the <root-
path> option remains.
MozReview-Commit-ID: 2UStBlU4JsG
--HG--
extra : rebase_source : 2c1828e063c1b3e772ac20c415fd34d0da1c24a6
Now using the the TYPE_APPLICATION_OVERLAY window type to display alert windows for devices running on Android O.
MozReview-Commit-ID: 7pdquyowbsB
***
***
--HG--
extra : rebase_source : fc07c2c2a34fe53583ba59fc27a7a6f75f4a812b
Bug details:
The problem stemmed from the now called GeckoPreferences.trySwitchToHeader(int id) which could be called with an invalid id, constant with the same value as the id of the last available setting.
(GeckoPreferenceFragment().getHeader() would return valid ids only for preference screens that are launched directly. Otherwise it would return: -1)
By chance the id for the last available setting - vendor was not set and so Android saw it with an invalid header id: -1.
GeckoPreferences.trySwitchToHeader(int id) would just switch to showing the vendor setting because that is what he has been instructed to whenever the user tried to access other settings than the ones which can be launched directly.
Cleaned the code a bit:
- renamed GeckoPreferences.switchToHeader(..) to trySwitchToHeader(..) as it won't always perform that action
- removed the call to activity.showBreadCrumbs(..) as in my tests it didn't have any effect and the documentation says "This will normally be called for you".
Tested on An Android 8 tablet, on an Android 8 phone, on an Android 5.0.1 phone and all works ok.
MozReview-Commit-ID: 2sbfcuRHgZd
--HG--
extra : rebase_source : 51f4629e89846d01224a0cd7dd8b3fba93657f40
Currently, if the "layout.accessiblecaret.allow_script_change_updates"
pref is false, we always hide accessible carets when the selection
changes due to JS calls (e.g. setSelectionRange(0, 1)). If the pref is
true, instead, we update the accessible carets if they are already
visible. In either case, we never show the carets if they're invisible.
However for testing purposes, it's useful to make it so we do try to
show the carets if they're invisible. This patch replaces that pref with
the new integer pref "layout.accessiblecaret.script_change_update_mode",
which can be 0 or 1, which correspond to the old pref, or the value 2,
which introduces this new behavior of always showing the carets.
MozReview-Commit-ID: Bf1gPpIzcyb
--HG--
extra : rebase_source : 5eaba6c18d800da425d5e21f61af880678d7fe3c
Added contentDescription strings for QR Code and Voice Input
MozReview-Commit-ID: 6tpoewhPxev
--HG--
extra : rebase_source : 3ed1f0263f108ad63131f99168ee9879f83fbdb2
Strings needed for this feature were added in a separate bug - 1445798 which were causing Lint errors.
When this feature will land there will be no need for the suppression.
MozReview-Commit-ID: IhtTS8rHLwz
--HG--
extra : rebase_source : 6c09445f7f8c6f6fb565f41e57f666e9cfc26627
The behavior of this new preference is dynamic in that:
- it will be hidden if LeanPlum is not available for the device
- it will be toggled off and disabled if Health Report is disabled by the user
MozReview-Commit-ID: 1x9zZukyygr
***
--HG--
extra : rebase_source : c31ad02cbbb106613914634b5192f856aad185b7
The Fennec CrashReporter class is also renamed to
CrashReporterActivity. When running in Fennec, the Activity will be used
which retains what we do today, prompting for comments, email, etc. When
used in standalone GeckoView, we report the crash without user
interaction if the appropriate GeckoRuntimeSetting was set. The app will
want to ask for user permission at least once in order to set this.
We do not collect the URL, email, or logcat with GeckoView crashes.
Logcat and URL would be nice to have, but it's not clear what the API
for those would look like, and they can be addressed in followup
patches.
MozReview-Commit-ID: C5ROsUKreRe
The Fennec CrashReporter class is also renamed to
CrashReporterActivity. When running in Fennec, the Activity will be used
which retains what we do today, prompting for comments, email, etc. When
used in standalone GeckoView, we report the crash without user
interaction if the appropriate GeckoRuntimeSetting was set. The app will
want to ask for user permission at least once in order to set this.
We do not collect the URL, email, or logcat with GeckoView crashes.
Logcat and URL would be nice to have, but it's not clear what the API
for those would look like, and they can be addressed in followup
patches.
MozReview-Commit-ID: C5ROsUKreRe
The current limit of at most one bfcache entry on Android dates back to when
Fennec was built for the Nokia N810, which had a whopping 128 MB of memory.
Since a few years have passed since then and mobile device technology has
evolved considerably, it should be safe now to allow a little more than that.
Since web sites sizes might have grown somewhat as well compared to the figure
of 4MB mentioned in CalcMaxTotalViweres(), though and to be absolutely on the
safe side, we still tweak the formula when building for Android, though.
If in the worst case even those assumptions turn out too generous, we will still
be protected by the fact that
- we temporarily disable the bfcache when the OS signals memory pressure, and
- our contentViewerTimeout is set to a lower value than on Desktop, so bfcache
entries will expire sooner
MozReview-Commit-ID: 1A6d0Q6Mdx0
--HG--
extra : rebase_source : 9cc1f7abb1aef82ffc4d7987773ae7cf35440884
Fix all Java warnings in the Android codebase except deprecation and
serial warnings, and warnings in third-party code.
There is one required change to exoplayer2 code under thirdparty,
because that code is included directly in the geckoview project, instead
of the thirdparty project. I think I'll just make a pull-request to
upstream the change, instead of separating exoplayer2 into a
gv-thirdparty project.
--HG--
extra : amend_source : 29419a24db9b956a7f3ee573a63f7a055ed90636
The Fennec CrashReporter class is also renamed to
CrashReporterActivity. When running in Fennec, the Activity will be used
which retains what we do today, prompting for comments, email, etc. When
used in standalone GeckoView, we report the crash without user
interaction if the appropriate GeckoRuntimeSetting was set. The app will
want to ask for user permission at least once in order to set this.
We do not collect the URL, email, or logcat with GeckoView crashes.
Logcat and URL would be nice to have, but it's not clear what the API
for those would look like, and they can be addressed in followup
patches.
MozReview-Commit-ID: C5ROsUKreRe
To allow users to opt-out from receiving LeanPlum messages we need a new setting added.
This are the Strings for the title and summary of that setting.
Localization notes also added as this Strings will ship before the feature.
Decided to suppress all UnusedResources Lint errors for android strings until the patch for #1454686 lands as using in-line suppression caused other errors.
Ran Lint locally, the build passed.
MozReview-Commit-ID: 9Kx567ruY3n
***
--HG--
extra : rebase_source : acb555719b4da9199364ca737ff140012dacb47c
This additionally introduces a new pref (toolkit.telemetry.isGeckoViewMode)
to discriminate, at runtime, between Fennec and GV in JavaScript code.
Moreover, this disables TelemetryController initialization from content
processes, which was left enabled.
MozReview-Commit-ID: 7VoDorxAhvD
--HG--
extra : rebase_source : b16a5c870c073f62175a5f9c2bf8db30032c55bd
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
This code was crashing in the framework; removing it should hopefully fix the
crash.
MozReview-Commit-ID: 2G3q4JrJ9tP
--HG--
extra : rebase_source : e9c1379b9dd3ebcb8ec2169165c629727344179d
At the moment the MediaControlService is structured such that it is started
shortly after Firefox has launched. Then, it registers a Tab event listener and
starts listening for various, mainly media-related tab events, in response to
which the playback notification is then shown or hidden as appropriate.
This setup has the drawback that the service itself has to remain running all
the time, even when we're not actually showing the notification, so Firefox now
keeps showing up as a "Running service" even when in background and not doing
anything interesting.
It is however relatively easily possible to move the tab event tracking into a
different class that won't require a service to stay alive, and set the Media-
ControlService's state (and at the same time start it if necessary) through a
set of special intent actions.
As the AudioFocusAgent is
a) alive for the whole lifetime of the application and
b) already interacting with the MediaControlService,
we designate it as the class responsible for this.
MozReview-Commit-ID: 1CzBpC1LTuZ
--HG--
extra : rebase_source : ef846bc1c52cb55fb1dfcdf05f2705f92358244e
Set process count to 1 because we only support one child process right
now.
MozReview-Commit-ID: HJAWvN4aqSX
--HG--
extra : rebase_source : 53e997b69b4b11fc3673a546ba0ad276e772d570
Set process count to 1 because we only support one child process right
now.
MozReview-Commit-ID: HJAWvN4aqSX
--HG--
extra : rebase_source : 8ade58427e8555f70a9349e6228b8aa7d1079781
Switch from the old XML-based AMO metadata API to the modern JSON based
API. This turned into something between a modest update and complete
rewrite. Most notably, external APIs became (mostly) promise-based. The
exception is getCachedAddonById() which XPIInstall.jsm requires a
synchronous callback from.
Also, hopefully we will be able to get rid of a bunch of this metadata
handling soon. If this code had a long life ahead of it, the unit tests
could use some more attention, but I mostly did the minimum here just to
keep them running for now with the expectation that we'll be able to get
rid of them within some small number of months.
MozReview-Commit-ID: 3DRaBdWGaiJ
--HG--
rename : services/sync/tests/unit/addon1-search.xml => services/sync/tests/unit/addon1-search.json
rename : services/sync/tests/unit/bootstrap1-search.xml => services/sync/tests/unit/bootstrap1-search.json
rename : services/sync/tests/unit/missing-sourceuri.xml => services/sync/tests/unit/missing-sourceuri.json
rename : services/sync/tests/unit/missing-xpi-search.xml => services/sync/tests/unit/missing-xpi-search.json
rename : services/sync/tests/unit/rewrite-search.xml => services/sync/tests/unit/rewrite-search.json
rename : services/sync/tests/unit/systemaddon-search.xml => services/sync/tests/unit/systemaddon-search.json
extra : rebase_source : f25d78b938768041c5c05b72a1f7ff3a7dee8275
In the next commit, we will send telemetry events in the sync ping.
The "event" JSON object doesn't have "uid"/"deviceID" fields (actually,
the "sync" objects shouldn't have them either!).
Let's do the right thing and send deviceID and UID as part of the top-level
"payload" object.
MozReview-Commit-ID: 3D3X3PcJAsW
--HG--
extra : rebase_source : 2ed71c7e6ce269cc43878f0e166dd9b149f3ccbc
In the next commit, we will send telemetry events in the sync ping.
The "event" JSON object doesn't have "uid"/"deviceID" fields (actually,
the "sync" objects shouldn't have them either!).
Let's do the right thing and send deviceID and UID as part of the top-level
"payload" object.
MozReview-Commit-ID: 3D3X3PcJAsW
--HG--
extra : rebase_source : 2ed71c7e6ce269cc43878f0e166dd9b149f3ccbc
These tests involve GeckoView classes, so move them to under geckoview/.
We use a custom test runner for Fennec unit tests, but I didn't notice
any problems when using standard test runners (e.g. MockitoJUnitRunner),
so I changed these tests to use standard runners.
MozReview-Commit-ID: 7JMhqJqahTC
--HG--
rename : mobile/android/app/src/test/java/org/mozilla/gecko/permissions/TestPermissions.java => mobile/android/geckoview/src/test/java/org/mozilla/gecko/permissions/TestPermissions.java
rename : mobile/android/app/src/test/java/org/mozilla/gecko/util/NetworkUtilsTest.java => mobile/android/geckoview/src/test/java/org/mozilla/gecko/util/NetworkUtilsTest.java
rename : mobile/android/app/src/test/java/org/mozilla/gecko/util/TestContextUtils.java => mobile/android/geckoview/src/test/java/org/mozilla/gecko/util/TestContextUtils.java
rename : mobile/android/app/src/test/java/org/mozilla/gecko/util/TestDateUtil.java => mobile/android/geckoview/src/test/java/org/mozilla/gecko/util/TestDateUtil.java
rename : mobile/android/app/src/test/java/org/mozilla/gecko/util/TestFileUtils.java => mobile/android/geckoview/src/test/java/org/mozilla/gecko/util/TestFileUtils.java
rename : mobile/android/app/src/test/java/org/mozilla/gecko/util/TestFloatUtils.java => mobile/android/geckoview/src/test/java/org/mozilla/gecko/util/TestFloatUtils.java
rename : mobile/android/app/src/test/java/org/mozilla/gecko/util/TestIntentUtils.java => mobile/android/geckoview/src/test/java/org/mozilla/gecko/util/TestIntentUtils.java
rename : mobile/android/app/src/test/java/org/mozilla/gecko/util/TestStringUtils.java => mobile/android/geckoview/src/test/java/org/mozilla/gecko/util/TestStringUtils.java
rename : mobile/android/app/src/test/java/org/mozilla/gecko/util/TestUUIDUtil.java => mobile/android/geckoview/src/test/java/org/mozilla/gecko/util/TestUUIDUtil.java
Removed FHR client id migration code on the Android side.
MozReview-Commit-ID: X9QKtbh6r3
--HG--
extra : rebase_source : f5587789f6980aecc4309dc329eb051650ad4c6f
The advantage of doing this per-variant is that we can really separate
the 'local' behaviour (re-generate via re-entrant |mach build|
invocations) from the 'official' behaviour (never re-generate via
re-entrance).
This also uses new Android-Gradle plugin 3.0+ APIs to integrate the
generated resources and Java code.
MozReview-Commit-ID: 4pd2iw1nJSb
--HG--
extra : rebase_source : 205080d3822f59bcdd5d3b44de2898ff775f5746
extra : source : 730a70767743b74a7e3a1fcf4018540edfdf30a3
There were a few API changes, mostly around explicitly creating
Services/Activities/ContentProvider instances, but they were pretty
easy to address.
Sadly, Robolectric doesn't really work with the new aapt2 processing
in Android-Gradle plugin 3.0+ -- see in particular
https://github.com/robolectric/robolectric/issues/3333#issuecomment-324300418
-- so we have to opt-out of the new implementation for now. Hopefully
plugin 3.1+ will address these issues, which are widespread.
MozReview-Commit-ID: dlbd32kMs6
--HG--
extra : rebase_source : fe30729161e5dc91ea9173f9b7aaa9135d096791
extra : source : 690e265c684ce70ecb89355314fd1574bb421f0b
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 22008e9333b15c594ce26c2a52f67396d6e3ab84
extra : source : f918500d9cf5112b70bc8e0a120df435b02252b7
Newer versions of Robolectric seem to have different semantics about
clearing disk caches, so this is necessary. But for older versions,
it shouldn't hurt, and is slightly more clear than relying on an
implicit clear.
MozReview-Commit-ID: LRcaEPasXj8
--HG--
extra : rebase_source : 4d6bb4916cde61f198004661bed58025e91ffa9c
extra : source : 373c9a71d9451498462594b302b4fe2648431fef
No idea what is going on with this hierarchy, but this isn't used and
isn't helping anything.
MozReview-Commit-ID: Ir3LxLYHR6M
--HG--
extra : rebase_source : f1726d37fa285de1042fed76a722f941380cbf63
extra : source : 3dc3beab95f83b2f08ff9ff305fdd4b85cc05d9d
This is just wrong.
MozReview-Commit-ID: EBtKTD07aNu
--HG--
rename : mobile/android/base/resources/values-v17/themes.xml => mobile/android/app/src/main/res/values-v17/themes.xml
extra : rebase_source : c6e58c6be966dd8ace6aa796b5a5e6000ee9c65e
extra : source : 22a861db1573364916ab2c5b6d0c6321ba08ff55
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : ce7c1585529e61491a0133633b976b27083c2372
extra : intermediate-source : f8b3e95f18e4082ab8404187508d09eadba8612e
extra : source : 8f1655752d43af33356d497d559888a967bbf6a0
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : 9de77b6278bae76df3597bc2580bcedbf6d33075
extra : intermediate-source : c6e6fe49ecd2dd422878d80f57f1c89bf69eebff
extra : source : 8f1655752d43af33356d497d559888a967bbf6a0
The Page menu is disabled when no tab is open, so not doing a null-check on the
currently selected tab in the menu click handler is safe.
MozReview-Commit-ID: CYKHJ5N1q8I
--HG--
extra : rebase_source : 3ec7b1a9708a905785850feb44b48723c24f1363
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : 4184f40d82bcd44c2bb380d1a8ab534967818af5
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : 0547c79ecf404688972fc55658f09bdfce07b613
This got mixed up by Bug 1411654, which migrated to Android-Gradle
3.0+. However, it's also much easier to fix due to the changes in the
new version! This patch uses the new audience flavor dimension to
control the version of LeakCanary included.
Note that this turns off LeakCanary for builds produced by |mach
build|, because |mach build| always builds the official audience
flavor dimension. We could use MOZILLA_OFFICIAL to differentiate, but
it's not worth it: local developers who care about LeakCanary
will/should be running a local audience flavor dimension from Android
Studio.
MozReview-Commit-ID: ASgxhNOMsWc
--HG--
extra : rebase_source : a5de2b6fdaf92a1d91739ca0b480a9d04d434b8c
The advantage of doing this per-variant is that we can really separate
the 'local' behaviour (re-generate via re-entrant |mach build|
invocations) from the 'official' behaviour (never re-generate via
re-entrance).
This also uses new Android-Gradle plugin 3.0+ APIs to integrate the
generated resources and Java code.
MozReview-Commit-ID: 4pd2iw1nJSb
--HG--
extra : rebase_source : 9e62ed6adf4b0fa01bcb9a927fa24626d3ce4d29
There were a few API changes, mostly around explicitly creating
Services/Activities/ContentProvider instances, but they were pretty
easy to address.
Sadly, Robolectric doesn't really work with the new aapt2 processing
in Android-Gradle plugin 3.0+ -- see in particular
https://github.com/robolectric/robolectric/issues/3333#issuecomment-324300418
-- so we have to opt-out of the new implementation for now. Hopefully
plugin 3.1+ will address these issues, which are widespread.
MozReview-Commit-ID: dlbd32kMs6
--HG--
extra : rebase_source : 325bc8142ec9b8a9d5029e7820e8f990d7e1a5fd
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 38a9781c472d858f3300cbbcbdc6d2311c465713
Newer versions of Robolectric seem to have different semantics about
clearing disk caches, so this is necessary. But for older versions,
it shouldn't hurt, and is slightly more clear than relying on an
implicit clear.
MozReview-Commit-ID: LRcaEPasXj8
--HG--
extra : rebase_source : 3b26f65d455c049b6190a9c481f8a4bec4e06dfd
No idea what is going on with this hierarchy, but this isn't used and
isn't helping anything.
MozReview-Commit-ID: Ir3LxLYHR6M
--HG--
extra : rebase_source : c883a3fa60d1a47b19b53f2bbc7a9c2f0e2cf711
This is just wrong.
MozReview-Commit-ID: EBtKTD07aNu
--HG--
rename : mobile/android/base/resources/values-v17/themes.xml => mobile/android/app/src/main/res/values-v17/themes.xml
extra : rebase_source : 01df9bd8ff4f2d700999ee5d2045890f8acb51ac
The advantage of doing this per-variant is that we can really separate
the 'local' behaviour (re-generate via re-entrant |mach build|
invocations) from the 'official' behaviour (never re-generate via
re-entrance).
This also uses new Android-Gradle plugin 3.0+ APIs to integrate the
generated resources and Java code.
MozReview-Commit-ID: 4pd2iw1nJSb
--HG--
extra : rebase_source : 7f8f8e7b2ec80de1104d51815ff2b66f389a33c3
There were a few API changes, mostly around explicitly creating
Services/Activities/ContentProvider instances, but they were pretty
easy to address.
Sadly, Robolectric doesn't really work with the new aapt2 processing
in Android-Gradle plugin 3.0+ -- see in particular
https://github.com/robolectric/robolectric/issues/3333#issuecomment-324300418
-- so we have to opt-out of the new implementation for now. Hopefully
plugin 3.1+ will address these issues, which are widespread.
MozReview-Commit-ID: dlbd32kMs6
--HG--
extra : rebase_source : 1b4a681863e8917b473f4852c4b88fe1f95dc1fd
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 5a5730b4b9ce84af40a7c73c4f1abba017103f02
Newer versions of Robolectric seem to have different semantics about
clearing disk caches, so this is necessary. But for older versions,
it shouldn't hurt, and is slightly more clear than relying on an
implicit clear.
MozReview-Commit-ID: LRcaEPasXj8
--HG--
extra : rebase_source : fee00a6a068d68e7f7978df56bcad94997d70afb
No idea what is going on with this hierarchy, but this isn't used and
isn't helping anything.
MozReview-Commit-ID: Ir3LxLYHR6M
--HG--
extra : rebase_source : d5efb14bff510e2a2982085237c53e27b4c7564d
This is just wrong.
MozReview-Commit-ID: EBtKTD07aNu
--HG--
rename : mobile/android/base/resources/values-v17/themes.xml => mobile/android/app/src/main/res/values-v17/themes.xml
extra : rebase_source : 6390d41a43e2724e81f4c0ae6c3122f487b3f4a4
- We already do this when packaging conventionally via ./mach package
- The omnijar is itself already a compressed archive, so no need to compress it
again
- Gecko (especially the GeckoJarReader) expects the file to be STORED within the
APK, doing otherwise may cause read access to the omnijar to fail
MozReview-Commit-ID: GcpeAehLe5h
--HG--
extra : rebase_source : b0c2562dc39f00541a9f3da308779c7ffe9fe584
Also remove related code that was only used from here including
stuff related to marketplace purchases, etc.
MozReview-Commit-ID: ESX78tVQK7M
--HG--
extra : rebase_source : 56d956168f75cdc40fd3df057e41493f80733352
This was in Gradle due to history. When this first landed, we invoked
Gradle directly from the mozharness, and the best way to print the
report URLs was from Gradle itself. When the Android Gradle suites
were made tier 1, little harnesses (|mach android
{checkstyle,findbugs,lint,test}|) were written and invoked locally and
in automation. This functionality should have migrated with them.
This removes the special Gradle target names from the Gradle
configuration, making it easier to change them in the future.
MozReview-Commit-ID: 1KPd3J5t82Q
--HG--
extra : rebase_source : 1da85e31c113bc9da138817bebf981af8b9b66dd
This was in Gradle due to history. When this first landed, we invoked
Gradle directly from the mozharness, and the best way to print the
report URLs was from Gradle itself. When the Android Gradle suites
were made tier 1, little harnesses (|mach android
{checkstyle,findbugs,lint,test}|) were written and invoked locally and
in automation. This functionality should have migrated with them.
This removes the special Gradle target names from the Gradle
configuration, making it easier to change them in the future.
MozReview-Commit-ID: 1KPd3J5t82Q
--HG--
extra : rebase_source : 1da85e31c113bc9da138817bebf981af8b9b66dd
The technique for setting our icon is just a straight reimplementation
of bug 1210242.
Because of the way the new tab might be opened from within a
processActionViewIntent Runnable, we can't enter editing mode by simply
listening for an ACTION_ASSIST intent from within BrowserApp, as we need to
enter editing mode *after* the correct tab has already been opened and selected
and BrowserApp doesn't get any hint on when that Runnable might have run.
Instead, we introduce a new tab event, so we can trigger editing mode at the
right time via the tab itself.
MozReview-Commit-ID: 8Bvv5TXyhhI
--HG--
extra : rebase_source : 92f6131098e1c2a8e810431aa82e68e7e422cfd1
This patch makes the :geckoview Gradle project only use
o.m.geckoview.BuildConfig, and makes the :app Gradle project use all
of the preprocessed code coming from the moz.build system.
Eventually, we'll reduce that set of preprocessed code to only
o.m.gecko.BuildConfig, which will then be produced by Gradle.
MozReview-Commit-ID: Dnkde7axyZL
--HG--
extra : rebase_source : dc0b7f9fa542cbfd9c665bfac761d45f5957f7b8
Upgrading to the Android-Gradle plugin 3.0+ broke |mach android test|
locally. This addresses the issue.
MozReview-Commit-ID: 3vV47ET7d19
--HG--
extra : rebase_source : c31e876969b0aff6cf7711fcb2227f6ca0d4fe46
This is part of a larger project to standardize our source locations.
MozReview-Commit-ID: Gbh9qSW7RJY
--HG--
rename : mobile/android/app/assets/example_asset.txt => mobile/android/app/src/main/assets/example_asset.txt
rename : mobile/android/app/assets/parental_controls_theme.png => mobile/android/app/src/main/assets/parental_controls_theme.png
rename : mobile/android/app/assets/publicsuffixlist => mobile/android/app/src/main/assets/publicsuffixlist
extra : rebase_source : dad3ded6a41d60989921b437dcf91181854c7b5a
Upgrading to the Android-Gradle plugin 3.0+ broke |mach android test|
locally. This addresses the issue.
MozReview-Commit-ID: 3vV47ET7d19
--HG--
extra : rebase_source : aaf7a550f8b2776a41d55fdce2c43c0c8c473331
This is part of a larger project to standardize our source locations.
MozReview-Commit-ID: Gbh9qSW7RJY
--HG--
rename : mobile/android/app/assets/example_asset.txt => mobile/android/app/src/main/assets/example_asset.txt
rename : mobile/android/app/assets/parental_controls_theme.png => mobile/android/app/src/main/assets/parental_controls_theme.png
rename : mobile/android/app/assets/publicsuffixlist => mobile/android/app/src/main/assets/publicsuffixlist
extra : rebase_source : e73b7d579e02984e6e2a4a3c746c515a69768568
Petru Lingurar
Andrei Lazar
alwu
Andreea Pavel
Tudor-Gabriel Vîjială
Andrew Swan
Jan Henning
Dennis Schubert
Matt Brubeck
Makoto Kato
Dale Harvey
Gurzau Raul
Chris Pearce
Jonathan Kingston
Bogdan Tara
Vlad Baicu
Kirk Steuber
Marco Bonardo
Karl Dubost
Tiberius Oros
James Willcox
Luca Greco
Cosmin Sabou
Chris H-C
Lee Salzman
Rob Wu
Eitan Isaacson
Michal Novotny
Jim Chen
s37syed
Michael Kaply
Noemi Erli
Andrew Gaul
Narcis Beleuzu
shindli
Alessio Placitelli
Brindusan Cristian
Nicholas Nethercote
Margareta Eliza Balazs
Nick Alexander
Cameron McCormack
Kris Maglione
Ryan VanderMeulen
Edouard Oger
Csoregi Natalia
Eugen Sawin
Timothy Guan-tin Chien
Suhail Alkowaileet
Thom Chiovoloni
Dylan Roeh
Jeremy Lempereur
Tad
Robert Helmer
Dorel Luca
John Lin
Ben Kelly
Nevin Chen
Ian Moody
Kilik Kuo
Dão Gottwald
Gijs Kruitbosch
Ciure Andrei
Sebastian Hengst