Tommy Nyquist
unread,Feb 24, 2023, 5:14:11 PM2/24/23Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to waf...@chromium.org, Peter Beverloo, boliu, Peter Wen, Justin Dewitt, Min Qin, ntf...@chromium.org, hart...@chromium.org, David Trainor, Charles Harrison, Richard (Torne) Coles, Shakti Sahu, chrome-up...@chromium.org, platform-c...@chromium.org, android-webview-dev, offli...@chromium.org, fe...@chromium.org, privacy-s...@chromium.org
Hi, Chromium developers.
I have recently made a few changes to the component by removing some old functionality that is either not necessary anymore, either directly not in use, or not considered required.
These are the most relevant changes are:
- Removed two task scheduling backends: GcmNetworkManager and AlarmManager. Neither were in use on supported versions of Android.
- Removed a migration step introduced in M78 of persisted scheduling metadata.
The most important CLs are listed here:
- 4114948: [android] Remove GcmNetworkManager based BackgroundTaskScheduler
- This removes the GcmNetworkManager backend.
- The GcmNetworkManager was only used on Android Lollipop and below, which is no longer supported (neither is Android Marshmallow for that sake).
- Expected impact: None
- First official build with change: 111.0.5536.0.
- 4200837: [android] Remove proto migration for background task scheduler
- Removes a migration of tasks that were scheduled on a version before M78.
- This new format and the migration code was introduced in M78. This is now considered so old that this CL removes the migration.
- Expected impact: Technically this could lead to issues when upgrading from a version before M78 to a recent version of Chrome. One use-case is if a user factory resets their whole device to an OS image that contains an old version of Chrome, and then uses Chrome before it's upgraded by the Play Store. This is considered highly unlikely, and is now an unsupported scenario.
- Workaround: Scheduling the task again from client code will resolve this as the JobScheduler internally stores the relevant information.
- First official build with change: 112.0.5577.0
- 4221854: [Android] Remove unused reschedule functionality from task API
- Without the GcmNetworkManager support, we never need to move tasks from one task scheduler to another one (GCM -> JobScheduler), so this mechanically removes this now-unused reschedule API.
- Expected impact: None
- First official build with change: 112.0.5582.0
- 4222142: [android] Use PersistableBundle in BackgroundTaskScheduler API
- This change moved the PersistableBundle usage to the public API and updated all callers.
- PersistableBundle was introduced in Android Lollipop and could not be used everywhere when the background task scheduler was introduced, so was only used internally.
- Expected impact: None, since this was already happening internally.
- First official build with change: 112.0.5602.0
- 4222339: [android] Remove support for BackgroundTaskScheduler exact timing API
- This removes the AlarmManager based backend.
- There should be no effect on clients for this as this was only ever used in one feature as part of an origin trial that is no longer active.
- Expected impact: None
- First official build with change: 112.0.5614.0
To make gathering the list of people to contact easier in the future, I
updated the task ID list with information about which component / team / owner is responsible. If I made a mistake here, and someone else should be listed, please tell me or send me a CL that fixes it! :-)
(If you wonder how I came up with the content, I first created this spreadsheet manually, and used DIR_METADATA and OWNERS from where the task ID was used, as well as what I knew from offline discussions.)
Feel free to reach out if you have any questions about these changes.
Regards
Tommy