Moved notification channels to NotificationHelper and created
new utility methods to retrieve them when needed. Cleaned unused
imports.
MozReview-Commit-ID: L3HnV3nD7Og
--HG--
extra : rebase_source : fdc18b8f31f76d988a3748b640e86607bb0b4186
Added a content action which will open the privacy settings when
tapping the mozilla location services notification.
MozReview-Commit-ID: 9h85amcoF0T
--HG--
extra : rebase_source : 8e8914e742023d3a6fb16397480df0d6eea6adb3
Because of the START_STICKY flag, upon boot completed, the service
would be started by the system which would trigger onStartCommand
and the notification being shown on Android Oreo+ devices without
a following call to onHandleIntent.
MozReview-Commit-ID: EldSSzRb7Zd
--HG--
extra : rebase_source : 2f39e499b744188e48adbdf03e426d9d50c45262
Also made broadcasts involving Stumbler explicit.
MozReview-Commit-ID: 7CK2Cr2JqX0
--HG--
extra : amend_source : 4a7de557ad76f6cb2a0dcad5419ec2b37ca89e05
On Android 7.0.0, the OS would start the StumblerService and without having given fennec the location permission the intent and scan enabled checks would've been skipped - which ensure that the Stumbler Service does not run in unadequate scenarios.
MozReview-Commit-ID: AGU67ytE4ff
--HG--
extra : rebase_source : 7d1285e75ffa233e4888e65505081bca2200b34e
Remove all references to Build.SDK_INT comparing 14 and lower
MozReview-Commit-ID: JdAjYvQ6mfX
--HG--
extra : rebase_source : f6cae8af84c26f42dcc02c133e7bc702f1af61e6
This solves 2 issues:
- We keep a reference to Tracker (which is implemented by a Service) forever,
which is solved by keeping a WeakReference.
- We kept another reference to the Service by using it as a Context - we can
avoid that by using the ApplicationContext instead.
MozReview-Commit-ID: 6UNSkZx12an
--HG--
extra : rebase_source : bfb50d02246e4377ef23179747987bc82731fd54
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
SafeReceiver is responsible for registering LocalReceiver with a LocalBroadcastManager.
SystemReceiver is responsible for handling BOOT_COMPLETE and EXTERNAL_APPLICATIONS_AVAILABLE intents.
LocalReceiver is responsible for handling passed in Stumbler preferences (enabled state, API key, user agent).
StumblerPreferences are now sent using LocalBroadcastManager, avoiding any possibility of leaking API key.
MozReview-Commit-ID: J8pRN6pbLOg
--HG--
rename : mobile/android/stumbler/java/org/mozilla/mozstumbler/service/mainthread/PassiveServiceReceiver.java => mobile/android/stumbler/java/org/mozilla/mozstumbler/service/mainthread/LocalPreferenceReceiver.java
extra : rebase_source : 0f11bb5aa38c27849f1a4f35ed51bdf259c418c8
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
This commit is us getting out of our own way. We were specifying
-classpath twice, once in $(JAVAC) and once in java-build.mk. Only
the latter of these is active. This a problem for ANDROID_EXTRA_JARS
-- those JARs should be on the classpath and input to $(DX) -- and
JARs that should be on the classpath but *not* input to $(DX). This
commit removes the global flags to $(JAVAC) and adds
JAVA_{BOOT}CLASSPATH_JARS. This required some hijinkery moving
wildcards to moz.build files, but everything seems to work.
As well as clarifying some parts of the build, part 2 uses this work
to modify the classpath.
--HG--
extra : commitid : 25Ft0BFs88O
extra : rebase_source : 05e3d1da8d42fa89d06ef48baee17bb77df5bd59
extra : histedit_source : 95b82309aca15c5a3c5f5a0eafbdcf75c5e8dfc0
This is just cruft; I didn't want to think about it when working on
the other parts. Bug 1196367 tracks removing the AndroidEclipse build
backend that consumed these definitions entirely.
--HG--
extra : commitid : 6fhp66SAwrq
extra : rebase_source : bdcab113f386d1083bcf558baec44e1640382514
extra : histedit_source : 4787ba24dae382eb904a8095285c4bac8a55cf56
Any class that has access to a context should call Prefs.getInstance(Context) which is guaranteed to return a Prefs.
With no context, classes can call Prefs.getInstanceWithoutContext() but they must null-check the return, and handle accordingly.
Fortunately, the latter case happens in very few places, all of which require no special handling of this case.
This change:
- maintains context-less access to the Prefs
- classes internal to the service can safely call getInstanceWithoutContext(), as the service (or the MainApp in the stumbler case)
will have instantiated a Prefs so that getInstanceWithoutContext() will return a prefs
- protects against null Prefs if we have failed to consider a particular entry point to the code will require that Prefs was instatiated with a context.
