Feature Request P3
Status Update
No update yet.
Comments
my...@gmail.com
Not at the moment. But we have been asked this before, so I will treat this as a feature request.
su...@google.com
OK thanks. At the moment I am just adding the name to the Data for the work request and retrieving it in startWork(), which works well enough.
ww...@google.com
does a WM with direct-boot aware implementation mean it will support DE(device encrypted) storage?
st...@baramundi.de
Now that you blocked the existing workaround to use your WorkManager with direct boot, is there a chance that we will get official direct boot support in the near future?
Our app relies heavily on WorkManager to ensure consistent task scheduling, and we were just about to implement direct boot support for our app.
The intentional exception forces us to consider using an alternative task scheduling, only to achieve direct boot support...
But going this way does not seem sensible. WorkManager is the official recommended way to schedule tasks by Google, not supporting direct boot AND taking away the conscious decision to use WorkManger in a device encrypted environment, does not make sense to me.
bb...@gmail.com
Expecting the response, any ETA of new WorkManager which supports direct boot aware?
[Deleted User] <[Deleted User]>
Any updates on Direct Boot mode support for WorkManager? If it is already available please specify the version here.
su...@google.com
ra...@google.com
my...@gmail.com
Wow now I can't even get around this issue thanks to this mean check. >:(
Fix when???
my...@gmail.com
I guess I can get around that too by override fun isDeviceProtectedStorage() = false. >:(
si...@gmail.com
Is there any progress on this? I have had to rework my code to use JobScheduler directly due to the lack of direct boot support for workmanager, it's a real shame
hu...@gmail.com
wow, journey from Aug 18, 2018 to 30 Aug 2024 was so shameful for this issue
Description
We should create a direct boot aware implementation of WorkManager. Ideally, this should involve the following steps:
1. Put common functionality into work-core
2. work-runtime includes work-core and provides WorkManager.getInstance()
3. A new artifact, work-directboot-runtime includes work-core and provides DirectBootWorkManager.getInstance() with its database in non-encrypted storage (note that the database is no longer a singleton)
The two instances cannot talk to each other but they should share the same components where possible. In particular, since direct boot is API 24+, it should only need to worry about JobScheduler. SystemJobService will need to delegate to the right implementation (potentially via a flag as part of the JobParameters). There will need to be a locked-boot-completed receiver for the new implementation. Finally, we should make sure no constraint-aware components are enabled/disabled without checking both instances, or that those components aren't shared. This *should* already be the case for API 24+.
More info about direct boot: