Status Update
Comments
ra...@google.com <ra...@google.com> #2
This is a particularly hard device to come by - do you happen to have access to the device? If so could you provide us with the output of: adb shell dumpsys media.camera > info.txt
Thanks!
ra...@google.com <ra...@google.com> #3
Stacktrace:
Caused by: java.lang.IllegalArgumentException: Can not get supported output size under supported maximum for the format: 34
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes(SupportedSurfaceCombination.java:355)
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions(SupportedSurfaceCombination.java:197)
at androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions(Camera2DeviceSurfaceManager.java:198)
at androidx.camera.core.CameraX.calculateSuggestedResolutions(CameraX.java:943)
at androidx.camera.core.CameraX.bindToLifecycle(CameraX.java:293)
at androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle(ProcessCameraProvider.java:227)
Below are some findings based on our debugging
When Dex is connected
previewConfig.getMaxResolution() is returning "731x411" as maxSize.
Inside Preview.Builder.build() -> Default_MAX_resolution is set to "CameraX.getSurfaceManager().getPreviewSize()" which is 731x411
this is being picked as maxSize.
While rendering maxSize is 731x411 and minSize is 640x480 and below are available outputSizes
0 = {Size@11860} "4032x3024"
1 = {Size@11861} "3984x2988"
2 = {Size@11862} "4032x2268"
3 = {Size@11863} "3024x3024"
4 = {Size@11864} "2976x2976"
5 = {Size@11865} "3840x2160"
6 = {Size@11866} "3264x2448"
7 = {Size@11867} "4032x1960"
8 = {Size@11868} "2880x2160"
9 = {Size@11869} "3264x1836"
10 = {Size@11870} "2160x2160"
11 = {Size@11871} "2560x1440"
12 = {Size@11872} "2224x1080"
13 = {Size@11873} "2048x1152"
14 = {Size@11874} "1920x1080"
15 = {Size@11875} "1440x1080"
16 = {Size@11876} "1088x1088"
17 = {Size@11877} "1280x720"
18 = {Size@11878} "1024x768"
19 = {Size@11879} "1056x704"
20 = {Size@11880} "960x720"
21 = {Size@11881} "960x540"
22 = {Size@11882} "720x720"
23 = {Size@11883} "800x450"
24 = {Size@11884} "720x480"
25 = {Size@11885} "640x480"
26 = {Size@11886} "352x288"
27 = {Size@11887} "320x240"
28 = {Size@11888} "256x144"
29 = {Size@11889} "176x144"
and couldn't find any size in this range.
When Dex not connected
minsize = 640x480
maxsize = 1920x1080
0 = {Size@11836} "4032x3024"
1 = {Size@11837} "3984x2988"
2 = {Size@11838} "4032x2268"
3 = {Size@11839} "3024x3024"
4 = {Size@11840} "2976x2976"
5 = {Size@11841} "3840x2160"
6 = {Size@11842} "3264x2448"
7 = {Size@11843} "4032x1960"
8 = {Size@11844} "2880x2160"
9 = {Size@11845} "3264x1836"
10 = {Size@11846} "2160x2160"
11 = {Size@11847} "2560x1440"
12 = {Size@11848} "2224x1080"
13 = {Size@11849} "2048x1152"
14 = {Size@11850} "1920x1080"
15 = {Size@11851} "1440x1080"
16 = {Size@11852} "1088x1088"
17 = {Size@11853} "1280x720"
18 = {Size@11854} "1024x768"
19 = {Size@11855} "1056x704"
20 = {Size@11856} "960x720"
21 = {Size@11857} "960x540"
22 = {Size@11858} "720x720"
23 = {Size@11859} "800x450"
24 = {Size@11860} "720x480"
25 = {Size@11861} "640x480"
26 = {Size@11862} "352x288"
27 = {Size@11863} "320x240"
28 = {Size@11864} "256x144"
29 = {Size@11865} "176x144"
and we have 12 available sizes in this range
Camera2DeviceSurfaceManager.java:: getPreviewSize()
mCameraSupportedSurfaceCombinationMap.get(cameraId).getSurfaceDefinition().getPreviewSize() = "1920x1080"
cameraId=0
ha...@gmail.com <ha...@gmail.com> #4
The issue root cause is that CameraX will default filter out sizes smaller than 640x480. For Preview, the max size will be limited to under display size. I checked the HW spec info for the issue related devices. Display size of FUJITSU F-04J/F-05J is 360x640. That will result int that no size exists in the conditions that is larger or equal to 640x480 and smaller or equal to 360x640.
A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
For device FUJITSU arrowsM04, I checked its HW spec info and its display size I found is 1280x720. It seems that the problem should not exist in the device.
Could you confirm that the problem exist on arrowsM04 device? What will be the returned value when using Display#getRealSize to obtain the display size?
da...@gmail.com <da...@gmail.com> #5
> A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
OK. I will try it.
> Could you confirm that the problem exist on arrowsM04 device?
We receive the crash report (Crashlytics) that this crash has occurred on arrowsM04.
We don't have this device so we can't confirm that the problem really exist on arrowsM04.
> What will be the returned value when using Display#getRealSize to obtain the display size?
We can't investigate it for the same reason.
Thank you.
da...@gmail.com <da...@gmail.com> #6
This issue happened on devices that the display size is smaller than 640x480. In original auto-resolution mechanism, supported sizes smaller than 640x480 will be default filter out.
The auto-resolution mechanism encodes the guaranteed configurations tables in CameraDevice#createCaptureSession(SessionConfiguration). It defines that the PREVIEW size is the small one of the device display size and 1080p. The PREVIEW size will be the maximal size limitation for Preview use case. The reason it limits the size to display size and 1080p is the stream output in display size or 1080p has been able to provide good enough preview quality. Therefore, auto-resolution mechanism will limit the selected size to be smaller than the small one of the device display size and 1080p.
With above two conditions, in this issue, all sizes smaller than 640x480 have been filter out, therefore, there is no size smaller than the display size 320x240 can be selected to use. And cause the exception.
Solution:
When the display size is smaller than 640x480, auto-resolution mechanism won't filter out those small sizes smaller than 640x480. This makes those small size be left and can be selected for the Preview use case on small display devices.
The solution has been merged and will be included in next CameraX release.
ra...@google.com <ra...@google.com> #7
Hello.
This crash still occurs.
- CAMERAX VERSION: 1.0.0-beta4
- ANDROID OS BUILD NUMBER: Android 7.1.1
- DEVICE NAME: FUJITSU F-02H
We receive following crash report from FUJITSU F-02H. So far We have received this crash report only from F-02H.
java.lang.IllegalArgumentException
Can not get supported output size under supported maximum for the format: 34
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes (SupportedSurfaceCombination.java:349)
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions (SupportedSurfaceCombination.java:197)
androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions (Camera2DeviceSurfaceManager.java:198)
androidx.camera.core.CameraX.calculateSuggestedResolutions (CameraX.java:949)
androidx.camera.core.CameraX.bindToLifecycle (CameraX.java:351)
androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle (ProcessCameraProvider.java:230)
(our application's package name).CameraFragment.bindCameraUseCases (CameraFragment.java:174)
ra...@google.com <ra...@google.com> #8
Could you help to provide the following information to clarify the issue?
1. Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
2. Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
da...@gmail.com <da...@gmail.com> #9
- Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
Yes
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
Since we don't have this device, we'll try to collect this information in the next version of our app. The next version will be released later this month.
da...@gmail.com <da...@gmail.com> #10
Hello.
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
We have collected the output of the device where the crash occurs.
Device1
- Model : arrows Be F-05J
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Device2
- Model : Fujitsu arrows M04
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Additional Information
CameraX version : 1.0.0-beta04
We collect the supported output sizes by following code.
val errorString = buildString {
append("The supported output sizes of ImageFormat.PRIVATE: ")
(requireContext().getSystemService(Context.CAMERA_SERVICE) as CameraManager).apply {
cameraIdList.forEachIndexed { index, cameraId ->
val msg = if (VERSION.SDK_INT >= VERSION_CODES.M) {
val configurationMap =
getCameraCharacteristics(cameraId).get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP)
val sizes = configurationMap?.getOutputSizes(ImageFormat.PRIVATE)
"CameraId $index: ${sizes?.joinToString(" ,")}"
} else {
"CameraId $index: This device version is under M."
}
append(msg)
}
}
}
da...@gmail.com <da...@gmail.com> #11
ra...@google.com <ra...@google.com> #12
I tried to find the device specs and both 720x1280
size display. For the camera id 0 device, it is a different case that the display size is larger than 640x480
but the device only supports a 480x480
size. The case also caused the same IllegalArgumentException and was also fixed by 1.0.0-beta04
release. Before 480x480
size would be filtered out and then caused the IllegalArgumentException. After it was merged, the 640x480
size threshold was removed and then the 480x480
size would be kept and selected to use.
It looks like 1.0.0-beta04
release had been used to collect the supported sizes information. But the issue should have been fixed by 1.0.0-beta04
release. Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
CameraX's 1.0.0-beta04
version. Maybe you can also consider to upgrade to the latest 1.0.0-rc01
version for your application. Thanks.
ra...@google.com <ra...@google.com> #13
Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
We collect informations only from the device on which IllegalArgumentException happened.
Our latest app uses CameraX version 1.0.0-beta10
and this issue still occurres.
However we don't receive crash report from Fujitsu arrows Be F-05J
or Fujitsu arrows M04
so far. (This doesn't mean this issue is fixed on these devices because our app is heavily rely on camera so these device's user wouldn't use our app anymore.)
Instead, we receive crash report from
- Model : Fujitsu F-03K
- Android Version : 7.1.2
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0 : 480x480
CameraId 1 : 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
da...@gmail.com <da...@gmail.com> #14
I missed some settings when I simulated the issue by robolectric test so that I was not able to reproduce it. Now, I can reproduce the issue if the device only supports one 480x480 resolution. I'm working on the solution and target to make it included in next release.
da...@gmail.com <da...@gmail.com> #15
Branch: androidx-main
commit 69d15dff7bb857ee33a0f643ff42a0f8bc475ab2
Author: charcoalchen <charcoalchen@google.com>
Date: Fri Jan 08 18:30:03 2021
Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Do not filter out sizes smaller than 640x480 when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Relnote:"Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480."
Bug: 150506192
Test: SupportedSurfaceCombinationTest
Change-Id: I2a63ce8e2ad42a9cc060c8635ac3603bf440b1ec
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/SupportedSurfaceCombination.java
M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/SupportedSurfaceCombinationTest.java
ra...@google.com <ra...@google.com> #16
da...@gmail.com <da...@gmail.com> #17
I'll update to the just released 2.3.0 version today and enable debug logging for WorkManager in production.
But i doubt that log will be included with the Crashlytics report unless the user get a crash report and manually click on send feedback.
If you have any idea on what i could do to extract more informations I'll try to help.
ey...@gmail.com <ey...@gmail.com> #18
java.lang.IllegalStateException:
at android.app.ContextImpl.startServiceCommon (ContextImpl.java:1666)
at android.app.ContextImpl.startService (ContextImpl.java:1611)
at android.content.ContextWrapper.startService (ContextWrapper.java:677)
at androidx.work.impl.Processor.stopForegroundService (Processor.java:303)
at androidx.work.impl.Processor.stopForeground (Processor.java:221)
at androidx.work.impl.WorkerWrapper.resolve (WorkerWrapper.java:453)
at androidx.work.impl.WorkerWrapper.rescheduleAndResolve (WorkerWrapper.java:546)
at androidx.work.impl.WorkerWrapper.onWorkFinished (WorkerWrapper.java:348)
at androidx.work.impl.WorkerWrapper$2.run (WorkerWrapper.java:318)
at androidx.work.impl.utils.SerialExecutor$Task.run (SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)
at java.lang.Thread.run (Thread.java:764)
Galaxy S9 (starqltesq) 339 23.2%
Galaxy Note9 (crownqltesq) 221 15.1%
Galaxy S9+ (star2qltesq) 203 13.9%
Galaxy S8 (dreamqltesq) 169 11.6%
Galaxy Note8 (greatqlte) 106 7.3%
Galaxy S8+ (dream2qltesq) 103 7.1%
Galaxy A50 (a50) 74 5.1%
Galaxy A20 (a20p) 32 2.2%
Galaxy A10e (a10e) 27 1.8%
Galaxy J3 V (j3topeltevzw) 27 1.8%
Galaxy S10+ (beyond2q) 16 1.1%
Galaxy J7 Refine (j7topeltespr) 14 1.0%
Galaxy A6 (a6eltespr) 13 0.9%
Galaxy S9 (starqlteue) 13 0.9%
Galaxy S8 Active (cruiserlteatt) 12 0.8%
Galaxy S8 (dreamqlteue) 12 0.8%
Galaxy A70 (a70q) 10 0.7%
Galaxy A20 (a20) 10 0.7%
Galaxy J7 Star (j7topltetmo) 8 0.5%
Galaxy J3 Orbit (j3topltetfntmo) 7 0.5%
Others 44 3.0%
ra...@google.com <ra...@google.com> #19
Thanks. One thing that is clear in your stack traces, is that WorkManager
was attempting to reschedule the Worker
. Let me continue investigating along those lines.
da...@gmail.com <da...@gmail.com> #20
But it looks like it is failing in the "resolve" part, so the reschedule should have been completed successfully.
ra...@google.com <ra...@google.com>
an...@google.com <an...@google.com> #21
ra...@google.com <ra...@google.com> #22
ha...@gmail.com <ha...@gmail.com> #23
ra...@google.com <ra...@google.com> #24
We are looking at the first week of February.
ey...@gmail.com <ey...@gmail.com> #25
Any way to get a snapshot or alpha build? I'm up to 6.5k crashes in the past 7 days. I can't roll back because it was an EOL update, and I can't remove WorkManager because it was needed for EOL behavior.
ra...@google.com <ra...@google.com> #26
You can try a snapshot build by doing the following:
repositories {
google()
maven { url 'https://ci.android.com/builds/submitted/6171913/androidx_snapshot/latest/repository/' }
}
dependencies {
implementation "androidx.work:work-runtime:2.4.0-SNAPSHOT"
}
ey...@gmail.com <ey...@gmail.com> #27
Got this on the snapshot. Almost 1,000 in the past 24 hours.
Fatal Exception: java.lang.IllegalStateException: Not allowed to start service Intent { act=ACTION_STOP_FOREGROUND cmp=com.myapp/androidx.work.impl.foreground.SystemForegroundService }: app is in background uid UidRecord{c03e72d u0a293 CEM bg:+15m4s172ms idle change:cached procs:1 proclist:3231, seq(0,0,0)} at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1666) at android.app.ContextImpl.startService(ContextImpl.java:1611) at android.content.ContextWrapper.startService(ContextWrapper.java:677) at androidx.work.impl.Processor.stopForegroundService(Processor.java:303) at androidx.work.impl.Processor.stopForeground(Processor.java:221) at androidx.work.impl.WorkerWrapper.resolve(WorkerWrapper.java:453) at androidx.work.impl.WorkerWrapper.rescheduleAndResolve(WorkerWrapper.java:546) at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:348) at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:318) at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.lang.Thread.run(Thread.java:764)
ra...@google.com <ra...@google.com> #28
Can you reproduce this locally at all ?
I am going to need a lot more information, to figure out what might be going on.
ey...@gmail.com <ey...@gmail.com> #29
I haven't seen it once locally. Any ideas on what I can try to do to get it to happen?
My use case is setting a recurring work that goes off every hour, and retrieves a location, and uploads it to a server. If the response is a 401 then I cancel the worker. I've tested all those scenarios multiple times.
ra...@google.com <ra...@google.com> #30
I am not exactly sure. While there is nothing wrong with your approach; rather than structure your work as a PeriodicWorkRequest
you might want to try doing something like:
Enqueue a OneTimeWorkRequest
which can do one of:
- Enqueue a copy of the same work request with an
initialDelay
of your period if you get a response that is not an HTTP401
. - No-op if you get an HTTP
401
.
That might be a much simpler way of managing this.
ey...@gmail.com <ey...@gmail.com> #31
Unfortunately we had to unpublish the app today, so I can't test anything further. But it seems like this bug is not fixed, at least in the 2.4.0-SNAPSHOT build.
ra...@google.com <ra...@google.com> #32
I made another change:
It should land soon. Unfortunately won't be in the 2.3.1 release. This is not strictly necessary from an API perspective, but anecdotally this seems to be required for some OEMs.
ey...@gmail.com <ey...@gmail.com> #33
This may also be relevant if you haven't seen it -
Basically if you start a foreground service you must call startForeground or the app will crash. If you stop the service before startForeground is called then the app will still crash.
ra...@google.com <ra...@google.com> #34
That part, is clear.
There is anecdotal evidence that a popular OEM requires you to call startForeground() as part of the first onStartCommand() callback when using ContextCompat.startForeground(...)
.
ey...@gmail.com <ey...@gmail.com> #35
I have had similar issues with that OEM in another app, even though I call startForeground
in onCreate
and in every onStartCommand
...
da...@gmail.com <da...@gmail.com> #36
This might be a stupid question...
We receive the crash in Crashlytics.
But does the user actually notice the bug? A popup saying the app crashed out of nowhere?
And does the crash affects in any way the rescheduling of the periodic work or the app functionality? How?
Bonus: is there something that us, as developers, can do in our apps to help you debug the issue? Even if it requires a snapshot version with some kind of logging + non-fatal exception sent to Crashlytics just before the startService that cause the crash, just to help you debug.
ra...@google.com <ra...@google.com> #37
- The good news is the user won't see this at all (its a background crash).
- No, it does not affect the app in any meaningful way. Because
WorkManager
has its own source of truth. Also, in this particular case your app process crashed while we were asking the foregroundService
to stop. Presumably, everything that the app wanted to do was already completed.
--
For being able to provide more information - what is really useful to us for cases like this which is hard to reproduce is WorkManager
s internal logs.
You can override the Logger
used by WorkManager
by using:
This is a @Restricted
API, however you can @Suppress
it. We might have a better API going forward, but it should be easy for you to change (if we do something i.e.)
ra...@google.com <ra...@google.com> #38
We made more changes to obviate the need for the ACTION_STOP_FOREGROUND intent itself. So you want to give this a go, you can try using:
repositories {
google()
maven { url 'https://ci.android.com/builds/submitted/6188671/androidx_snapshot/latest/repository/' }
}
dependencies {
implementation "androidx.work:work-runtime:2.4.0-SNAPSHOT"
}
ra...@google.com <ra...@google.com> #39
My apologies, it looks like the artifacts were not generated for that build. I have verified that this one works:
repositories {
google()
maven { url 'https://ci.android.com/builds/submitted/6217200/androidx_snapshot/latest/repository/' }
}
dependencies {
implementation "androidx.work:work-runtime:2.4.0-SNAPSHOT"
}
ha...@gmail.com <ha...@gmail.com> #40
Can someone confirm that it's now fixed with 2.4.0? When will this release be available in the stable channel?.
This issue here is marked as "fixed" so it should be working now?!
ra...@google.com <ra...@google.com> #41
The fix also landed in version 2.3.2
.
pa...@gmail.com <pa...@gmail.com> #42
I am using workManager v2.7.1 and I am seeing this error locally and really often when I started to use
setForegroundAsync(foregroundInfo) because of android 12 restrictions on foreground services.
Unable to stop foreground service android.app.BackgroundServiceStartNotAllowedException: Not allowed to start service Intent { act=ACTION_STOP_FOREGROUND cmp=com.xx.xx/androidx.work.impl.foreground.SystemForegroundService }: app is in background uid UidRecord{3b1d726 u0a271 LAST bg:+2m45s924ms idle change:idle|procstate procs:0 seq(2348929,2348732)} at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1908) at android.app.ContextImpl.startService(ContextImpl.java:1864) at android.content.ContextWrapper.startService(ContextWrapper.java:817) at androidx.work.impl.Processor.stopForegroundService(Processor.java:318) at androidx.work.impl.Processor.stopForeground(Processor.java:224) at androidx.work.impl.WorkerWrapper.resolve(WorkerWrapper.java:460) at androidx.work.impl.WorkerWrapper.resetPeriodicAndResolve(WorkerWrapper.java:571) at androidx.work.impl.WorkerWrapper.handleResult(WorkerWrapper.java:475) at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:354) at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:331) at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637) at java.lang.Thread.run(Thread.java:1012)
ha...@gmail.com <ha...@gmail.com> #43
he...@gmail.com <he...@gmail.com> #44
Also getting the same error from doWork expedited CoroutineWorker
method if App in background.
Unable to stop foreground service
android.app.BackgroundServiceStartNotAllowedException: Not allowed to start service Intent { act=ACTION_STOP_FOREGROUND cmp=com.example.example/androidx.work.impl.foreground.SystemForegroundService }: app is in background uid UidRecord{1248515 u0a294 TRNB bg:+1m39s883ms idle change:uncached procs:0 seq(0,0,0)}
at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1862)
at android.app.ContextImpl.startService(ContextImpl.java:1818)
at android.content.ContextWrapper.startService(ContextWrapper.java:776)
at androidx.work.impl.Processor.stopForegroundService(Processor.java:318)
at androidx.work.impl.Processor.stopForeground(Processor.java:224)
at androidx.work.impl.WorkerWrapper.resolve(WorkerWrapper.java:460)
at androidx.work.impl.WorkerWrapper.setSucceededAndResolve(WorkerWrapper.java:600)
at androidx.work.impl.WorkerWrapper.handleResult(WorkerWrapper.java:477)
at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:354)
at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:331)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
Only service is setForeground
method using:
if (Build.VERSION.SDK_INT > Build.VERSION_CODES.R) {
setForegroundAsync(createForegroundInfo())
} else setForeground(createForegroundInfo())
doWork is uploading Room data and images.
Description
Version used: 2.3.0-beta01
Devices/Android versions reproduced on: Galaxy A7 (Android 9) / Galaxy S10 (Android 10)
versions.build = [
minsdk : 23,
targetsdk : 29,
buildtools: "29.0.2",
]
---
I get a crash after start using the new foreground API in 2.3.0. I'm using `CoroutineWorker` and calling `setForeground()` in its `doWork()` with a notification which has an action created by `WorkManager.getInstance(context).createCancelPendingIntent(id)`. This should stop the job when clicked.
This seemed to work fine but after releasing, it crashes for some users with the following stacktrace (on Android 10; on Android 9 the line is 1666 instead of 1687):
```
Fatal Exception: java.lang.IllegalStateException: Not allowed to start service Intent { act=ACTION_STOP_FOREGROUND cmp=de.loewen.lcsmobile/androidx.work.impl.foreground.SystemForegroundService }: app is in background uid UidRecord{da09b33 u0a309 CEM idle change:cached procs:1 proclist:29769, seq(0,0,0)}
at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1687)
at android.app.ContextImpl.startService(ContextImpl.java:1632)
at android.content.ContextWrapper.startService(ContextWrapper.java:683)
at androidx.work.impl.Processor.stopForegroundService(Processor.java:303)
at androidx.work.impl.Processor.stopForeground(Processor.java:221)
at androidx.work.impl.WorkerWrapper.resolve(WorkerWrapper.java:453)
at androidx.work.impl.WorkerWrapper.setFailedAndResolve(WorkerWrapper.java:519)
at androidx.work.impl.WorkerWrapper.handleResult(WorkerWrapper.java:485)
at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:343)
at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:318)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
```
I've looked into the changelog of 2.3.0-beta02 but it doesn't seem like there's already a fix for this problem.
The stacktrace doesn't contain a line of my app, only the workmanager-library so I think its crashing after the users clicks the cancel-action on the notification.