In the case of an unbound pivot (endOffset == startOffset == -1), we
should move to the last substring in the current position when
movePreviousByText is called.
Also made broadcasts involving Stumbler explicit.
MozReview-Commit-ID: 7CK2Cr2JqX0
--HG--
extra : amend_source : 4a7de557ad76f6cb2a0dcad5419ec2b37ca89e05
Added reading permission as a safety measure for any future android updates.
MozReview-Commit-ID: Be6V8hn9KF8
***
--HG--
extra : amend_source : 501deb367f68b0592a1d91015c640782700c62f3
Modified NotificationClient to use new start/stop intents for NotificationService for
Android O. We are keeping a reference to the notification the service was first
started with in order to comply with the mandatory startForeground call for Oreo.
MozReview-Commit-ID: 4CzM4pvANJt
--HG--
extra : amend_source : 3bb93cae58b214c680a3ea67fe60d3680767b558
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
Refactored existing LeanplumPushInstanceIDService to support Oreo background
execution limits in Leanplum after upgrade.
MozReview-Commit-ID: JjUlrOv34KR
***
--HG--
extra : amend_source : df46ff00a671a02dc1c6fda3d0402d9216d7e84f
Made all the notifications within the app to use notification channel for devices with API26 and higher.
MozReview-Commit-ID: CVmpitNsS66
--HG--
extra : amend_source : 6628a1e06975e23b7b38a43650df12c9835cb3ee
Listening for `ACTION_MY_PACKAGE_REPLACED` [1] is the easiest way to get notified
when the app has been updated.
This broadcast, while not explicitly exempt from Oreo's Background Execution
Limits [2] is considered explicit because it is sent only to the package being
replaced and so it is compatible with the new limitations.
The previous intent action was chosen because at that time this action was not
supported by all platforms Fennec ran on [3], but this is not the case anymore.
[1] https://developer.android.com/reference/android/content/Intent.html#ACTION_MY_PACKAGE_REPLACED
[2] https://developer.android.com/guide/components/broadcast-exceptions
[3] 5c06063be6
MozReview-Commit-ID: Ak0dd2koJ9U
--HG--
extra : rebase_source : 58f32f574b13e5d7e9256f578821445eae1e3b57
extra : histedit_source : 204d858fe7408276714b2d228b612baddf76804d
This Receiver was used for implicit broadcasts and registered statically.
Refactored MmaDelegate() to register it dynamically in the init() method,
called in activity's onCreate and unregister it in activity's onDestroy.
This way we will still get notified immediately if the user installs any of
the apps we are interested in, even though he might not return to Fennec
immediately after. This will help to better asses the impact of suggestions to
install recommended packages.
For the cases in which the user installs the packages without us suggesting to
or if he kills our app before completing the new install, we will trigger a
check for the install status of the packages in MmaDelegate().init().
Also cleaned the code a little.
MozReview-Commit-ID: I00mLS2snzj
--HG--
extra : rebase_source : 9d767744dc3f4f2a44ab6de67c20f68a137a3beb
extra : histedit_source : e33a46fe4ece77b08eb8c9d161513e669fc14631
The only change needed was to make sure the broadcast for
NotificationHelper.HELPER_BROADCAST_ACTION is sent explicitly to
our receiver.
The other 2 broadcasts that this receiver listens for are already explicit.
MozReview-Commit-ID: C3A88ijqIsd
--HG--
extra : rebase_source : bd6beb4a6b5656b59ee61d0122a133042d77e380
extra : histedit_source : 63103038680580f5e30082e245fb0be5168529eb
Listening for `ACTION_MY_PACKAGE_REPLACED` [1] is the easiest way to get
notified when the app has been updated.
This broadcast, while not explicitly exempt from Oreo's Background Execution
Limits [2] is considered explicit because it is sent only to the package being
replaced and so it is compatible with the new limitations.
The previous intent action was chosen because at that time this action was not
supported by all platforms Fennec ran on [3], but this is not the case anymore.
The other broadcast - `ACTION_NOTIFICATION_CANCELLED` that this receiver
listens to is send explicitly.
[1] https://developer.android.com/reference/android/content/Intent.html#ACTION_MY_PACKAGE_REPLACED
[2] https://developer.android.com/guide/components/broadcast-exceptions
[3] 5c06063be6
MozReview-Commit-ID: DLUdw906i3P
--HG--
extra : rebase_source : a8544ae169344896aba4c7b922b68af4ad4bc94c
extra : histedit_source : c41c60cedea452ba8662fa836faa2aa8f9b5627e
Whenever the GCM token expires it need to be refreshed.
For this, after targeting Android 8.0 (API level 26) or higher
Google recommends using a JobIntentService
https://developers.google.com/cloud-messaging/android/client
MozReview-Commit-ID: 1vz092TQfbz
--HG--
extra : amend_source : afecc9454dd64c1b0a83bc469d7cf201909ee2ae
This simple Service needed to be migrated to JobIntentService because it could
be started from background and we don't want it as a foreground service
(with a notification).
(For example: when the app is updated org.mozilla.gecko.PackageReplacedReceiver
would try and start this service. If in background, the app would crash)
Had to break the initial Service into separate JobIntentServices because in the
event that there are concurrent calls (even with different Intent actions)
JobScheduler would assume they are for the same already running service.
INTENT_ACTION_UPDATE_ADDONS was removed as it was being unused.
MozReview-Commit-ID: 2GiWFZdAVvp
--HG--
extra : amend_source : 7236a78707b781ee24eafe1e69662c10bd6a0ea6
Use the fact that a JobIntentService is still a Service to keep most of the
previous implementation and method of starting CrashReportingService.
On 26+ devices it will be called with "start-foreground-service".
This ensures it can be started even from background and the crash reporting
process would work as before but ActivityManager will post an ANR error to
logcat after 5 seconds because we aren't calling Service.startForeground()
(which would mean a user visible notification).
Will use different Job Ids depending on if the app is Firefox Release or
Firefox Beta.
The Job Id will be passed to GeckoThread when first initializing and then be
made available to CrashHandler and nsExceptionHandler.cpp to be sent in the
Intent that starts the CrashReporterService.
MozReview-Commit-ID: GATl6Waa9St
--HG--
extra : amend_source : 70bc130b9411df336181e825ebb3e19bdc5a778c
Broke the big IntentService into four small JobIntentServices because
the same JobIntentService class cannot be used with multiple JobIds
(b6838fd2d2/compat/src/main/java/android/support/v4/app/JobIntentService.java (L121))
Also:
- will make the code easier to be migrated to WorkManager in the future
- more in line with SRP. It was initially doing too much.
All the functionality of the big UpdateService class has been incorporated in
Updater.java, UpdatesPrefs.java and UpdatesServiceHelper.java
with the main logic to drive the important actions inside the new Services.
UpdaterService is used as parent of the newly created service to help avoid
duplicated code.
Created an inner BroadcastReceiver to act upon notification actions while
the service which posted it is running as it's state needed to be modified.
Created a BroadcastReceiver to act on actions from notifications which remained
posted after the service that posted them finished. This receiver will just
start another UpdaterService.
Otherwise the services are to be started from the UpdateServiceHelper class.
MozReview-Commit-ID: 2OyBZ4YYvgh
--HG--
extra : rebase_source : 17b98a1209409c09227490ca66d75d8d37717a6e
Broke the big IntentService into four small JobIntentServices because
the same JobIntentService class cannot be used with multiple JobIds
(b6838fd2d2/compat/src/main/java/android/support/v4/app/JobIntentService.java (L121))
Also:
- will make the code easier to be migrated to WorkManager in the future
- more in line with SRP. It was initially doing too much.
Cleaned the code a little, removed the superfluous creation of new Threads for
DownloadContentCatalog().persistChanges() / .startLoadFromDisk()
as those methods are always called from the background threads
of the new JobIntentServices.
The new DlcHelper helps reducing duplicated code.
MozReview-Commit-ID: G3fsWYOGEbR
--HG--
extra : rebase_source : 5bdc3e64a44b7a3f77743b2b2f8f5d528a7b51c3
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL