Status Update
No update yet.
Comments
il...@google.com
to...@gmail.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.
il...@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.
ta...@gmail.com
Another similar issue that's related
il...@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.
il...@google.com
Why isn't the emulator tested more on Windows OS?
Windows OS is more popular than Linux and MacOS combined (on desktop) ...
vo...@gmail.com
kk...@google.com
I reproduced this bug on Windows with emulator version 31.2.10-8420304
ku...@gmail.com
ku...@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
ku...@gmail.com
@11 So it could be the same reason that this bug occurs:
?
gs...@gmail.com
RE#12 I have uploaded a
Description
Callback order is changed when calling restartLoader.
The documentation of restartLoader Says: "If a loader with the same id has previously been started it will automatically be destroyed when the new loader completes its work. The callback will be delivered before the old loader is destroyed."
But new implementation does not that at all. It calls onLoaderReset then onCreateLoader then onLoadFinished. (Previous implementation was sometimes broken and never called onLoaderReset but at least there was no long duration where we have no data to display).
This is a major change because this means you can't keep the previous data during the load as it's invalidated but you have nothing to display since the new loader is not finished. Meaning empty screen on reload = quite bad UX.