Status Update
No update yet.
Comments
ra...@google.com
ra...@google.com
lblb636@ Thanks for reporting this bug. I just want to confirm that the issue is the call device button being not responsive according to the uploaded video. It seems like this issue only happened on Windows.
ap...@google.com
And why only from specific API of Android?
On API 28 for example, it doesn't occur...
Please fix this issue for all API versions of the emulator.
pe...@gmail.com
Another similar issue that's related
ra...@google.com
RE#4 I need to try this on Windows laptop first and I couldn't repro on MacOS or Linux. But I think this is most likely related to the modem simulator we introduced for API 31. Will need to further investigate.
pe...@gmail.com
Why isn't the emulator tested more on Windows OS?
Windows OS is more popular than Linux and MacOS combined (on desktop) ...
pe...@gmail.com
ra...@google.com
I reproduced this bug on Windows with emulator version 31.2.10-8420304
ra...@google.com
pe...@gmail.com
Found the root cause when the "call device" button was unresponsive. It became unresponsive because the inbound call failed to initialize. Basically, the modem simulator's shared FD failed. When receive_inbound_call is invoked, it is supposed to make connection to the "host server" via a shared fd but it is flaky on Windows unfortunately.
modem-simulator: receive_inbound_call:101 inbound call from 6505551212
modem-simulator: process_msgs:296 waiting for new messages ...
modem-simulator: main_host_thread:501 got connection at host server at 65094
modem-simulator: start_calling_thread:254 making a connection to main host server 65094
modem-simulator: main_host_thread:507 Detected close from the other side
modem-simulator: start_calling_thread:262 nothing read quit
modem-simulator: main_host_thread:494 looping at main host server at 65094
modem-simulator: start_calling_thread:284 done with this thread
ra...@google.com
@11 So it could be the same reason that this bug occurs:
?
pe...@gmail.com
RE#12 I have uploaded a
su...@google.com
Have you tested it on all API versions, to make sure that it doesn't cause new issues, and also fixes the issue on other places in case it's there too?
pe...@gmail.com
RE#14 This issue is for API 31+, I will check for API 32 and API 33. Thanks for reminding me.
ra...@google.com
pe...@gmail.com
When will the fix be available?
jo...@truecaller.com
The fix has been merged in both 31 release and 32 release for since 05/2022.
su...@google.com
On which version ?
ra...@google.com
So the fact that more jobs are being scheduled is very interesting (because they should not be).
Can you please provide us with some more information ?
* How are you initializing WorkManager ?
* Are you creating any WorkRequest's on app startup ? If so what kind of work requests are they ?
* Are you scheduling work using JobScheduler on your own, apart from WorkManager ?
* How many users (total) and the population (total) got effected ? (Just to get an idea of % of users effected). What devices were they on? What versions of Android ?
* Can you send us a sample app that reproduces the problem ?
Description
Version used: 1.0.0-rc01
Devices/Android versions reproduced on: Nexus 6, API 25 (7.1.1)
Description:
If an app crashes while a Worker is being executed, then new submitted Workers aren't executed, even after the app is restarted. The WorkManager will not resume any further work execution at any time, neither if waiting for several minutes.
So far, seen only when sending OneTimeWorkRequest works with enqueueUniqueWork or beginUniqueWork.
The issue started to appear in version 1.0.0-rc01
Find attached a test project. Once run the app shows the steps to reproduce the issue.