Status Update
Comments
ra...@google.com <ra...@google.com> #2
Thank you for the report. We will try to fix this soon. In the meantime, could you please start the emulator from the console (see the commands below), open the camera app to crash it and attach the output, it might help to figure out what the problem is:
cd /Users/YOUR_USERNAME/Library/Android/sdk/emulator
./emulator -list-avds
./emulator -verbose -avd YOUR_AVD_FROM_PREVIOUS_STEP
if there is a crash report to send, please send it and attach the report id.
su...@google.com <su...@google.com> #3
We got a crash report (thanks JP): 872e3b20bc34905b. It says EXC_BAD_INSTRUCTION / 0x00000001
and the console also says "Illegal hardware instruction". I suspect the new MacOS brought a new hypervizor which causes this behavior. Haitao, could you please take a look?
dr...@gmail.com <dr...@gmail.com> #4
We have quite some crashes like this:
product_name="AndroidEmulator" AND crash.Reason="EXC_BAD_INSTRUCTION / 0x00000001" AND cpu.Architecture="arm64"
dr...@gmail.com <dr...@gmail.com> #5
The most of crashes happen here:
vVertical_Scale_ARGB_8888_Accelerate
vImageVerticalShear_ARGB8888
vImageVerticalShear_ARGB8888
vImageScale_ARGB8888
vRotateClockwise270Degree_ARGB8888_Accelerate2
vRotate_90_ARGB_8888_270Degree_Accelerate2
dr...@gmail.com <dr...@gmail.com> #6
I suspect EXC_BAD_INSTRUCTION
happens in vImageRotate90_ARGB8888
and vImageScale_ARGB8888
which are used by webcam on MacOS.
dr...@gmail.com <dr...@gmail.com> #7
su...@google.com <su...@google.com> #8
Hi rforzani22, I am sorry for this experience. This bug is my top priority. We expect a fix to be merged within a week. You should be able to download a build directly from our build server (
ra...@google.com <ra...@google.com> #9
ra...@google.com <ra...@google.com> #10
We confirmed vImageRotate90...
and vImageScale...
and use what I could find (which is not as efficient as vImage...
ones, we will try to figure out why these functions crash), it does not handle all aspect ratios and resolutions so far (it might crash for different reasons, I will be working on this tomorrow). If anyone wants to try my local build, I can share it.
dr...@gmail.com <dr...@gmail.com> #11
su...@google.com <su...@google.com> #12
dr...@gmail.com <dr...@gmail.com> #13
su...@google.com <su...@google.com> #14
rforzani22 and treblew2017, I shared a Google Drive link with you, see your email.
dr...@gmail.com <dr...@gmail.com> #15
dr...@gmail.com <dr...@gmail.com> #16
lechun.sk, I shared with you.
dr...@gmail.com <dr...@gmail.com> #17
su...@google.com <su...@google.com> #18
lechun.sk, this is unexpected. Do you mind uploading a crash report and sharing its id?
dr...@gmail.com <dr...@gmail.com> #19
ra...@google.com <ra...@google.com> #20
lechun.sk, unfortunately a bug report will not help here. It would useful to debug issues inside Android. This crash happens outside. There should be a popup window when you start the emulator asking to send a crash report. Maybe it is not available for local builds. The fix is in code review.
ra...@google.com <ra...@google.com> #21
dr...@gmail.com <dr...@gmail.com> #22
Do you mind trying API34? We have a new camera HAL there.
dr...@gmail.com <dr...@gmail.com> #23
dr...@gmail.com <dr...@gmail.com> #24
dr...@gmail.com <dr...@gmail.com> #25
dr...@gmail.com <dr...@gmail.com> #27
ap...@google.com <ap...@google.com> #28
But it lags
yes, it does, because our rotation is not as efficient as vImageRotate90_ARGB8888.
and then crashes
I can't repro it with a build-in camera in my laptop. What camera do you use? Do you see a crash upload dialog to upload it (please share the ID if you have one)?
dr...@gmail.com <dr...@gmail.com> #29
I can't repro it with a build-in camera in my laptop. What camera do you use?
You can use OBS Studio or XSplit VCam to create a virtual webcam, or you can purchase any Logitech camera, both of which should cause a crash.
Do you see a crash upload dialog to upload it (please share the ID if you have one)?
The dialog doesn't appear at all.
ra...@google.com <ra...@google.com> #30
dr...@gmail.com <dr...@gmail.com> #31
You can use OBS Studio
No crash, see the emulator screen recording. What resolution do you use in OBS Studio?
dr...@gmail.com <dr...@gmail.com> #32
What resolution do you use in OBS Studio?
1280 * 720. By the way, I'm using mac mini 2023(M2).
- simulator version: sdk-repo-darwin_aarch64-emulator-10914596
- log(only four lines)
VERBOSE | Timed out with running command |/Users/user/Library/Android/sdk/platform-tools/adb -s emulator-5554 shell am broadcast -a com.android.emulator.multidisplay.START -n com.android.emulator.multidisplay/.MultiDisplayServiceReceiver |
[54176:8959974:20231007,XXXXXX.766822:WARNING in_range_cast.h:38] value -634136515 out of range
[54176:8959974:20231007,XXXXXX.823661:WARNING crash_report_exception_handler.cc:235] UniversalExceptionRaise: (os/kern) failure (5)
[1] 54174 illegal hardware instruction emulator -avd Test_Pixel_5_API_31 -verbose
su...@google.com <su...@google.com> #33
1280 * 720
Still cannot reproduce, unfortunately. I put 60FPS to match your screenshot. I also tried 720*1280, it even crops correctly.
I'm using mac mini 2023(M2)
MacBook 2021 (M1 Max).
dr...@gmail.com <dr...@gmail.com> #34
su...@google.com <su...@google.com> #35
The emulator camera is very slow
dr...@gmail.com <dr...@gmail.com> #36
Unfortunately, I don't have an update as it works for me (somewhat slow, yes).
dr...@gmail.com <dr...@gmail.com> #37
Hi
In case anybody is still experimenting a crash with
crashreport -l
to see if a local crash has been createdcrashreport -u
to upload the crash (if any). It will give a crash report-id, and please enter the crashid as a comment of this bug. It will help us if you can also say what you were doing during the crash, and if you were using a specific webcam
crashreport
being part of the zipfile sdk-repo-darwin_aarch64-emulator-10914596.zip
We were able to reproduce the crashes on different MacOS running Sonoma before the fix in 10914596, but since the fix, the emulator is not crashing anymore in our tests on Sonoma.
Thanks
ra...@google.com <ra...@google.com> #38
ra...@google.com <ra...@google.com> #39
You want to download the file (sdk-repo-darwin_aarch64-emulator-10914596.zip
) and
xattr -d com.apple.quarantine sdk-repo-darwin_aarch64-emulator-10914596.zip
then unzip it.
dr...@gmail.com <dr...@gmail.com> #40
ra...@google.com <ra...@google.com> #41
So how do I open it?
Start it from the console, e.g. ANDROID_SDK_ROOT=/Users/rforzani22/Library/Android/sdk ./emulator -avd YOUR_AVD -wipe-data -no-snapshot -camera-back webcam0
dr...@gmail.com <dr...@gmail.com> #42
dr...@gmail.com <dr...@gmail.com> #43
Hi skergx, thank you for the feedback. What CPU do you run on?
su...@google.com <su...@google.com> #44
dr...@gmail.com <dr...@gmail.com> #45
dr...@gmail.com <dr...@gmail.com> #46
We are working on a better patch (the performance should be about as before and should also work on non-Max CPUs as we see here), the build should be available today-tomorrow.
ra...@google.com <ra...@google.com> #47
I shared my local build with our next patch to fix this issue.
dr...@gmail.com <dr...@gmail.com> #49
dr...@gmail.com <dr...@gmail.com> #50
Report 7d004e0f-9c06-49d8-b57e-30cd0fe4f033 is available remotely as d6281b959cb2c138
Report 149d7151-6381-46a2-83f8-1d77ab7280f3 is available remotely as 96a1cd1205509b81
dr...@gmail.com <dr...@gmail.com> #52
Hi Andi, the Android Emulator is released independently from the Android Studio. The 32.x.x version is EOL, 33.x.x will be promoted to stable soon and the webcam fixes will be available there.
ra...@google.com <ra...@google.com> #53
dr...@gmail.com <dr...@gmail.com> #54
- seems the performance is not the same as before (as already reported)
- also the image has different size as before, at least with obs before sonoma i was seeing a cropped image out of the 1280x720 but now i can see it full size on the emulator screen.
- it crash after some time (as already reported) see here: Report 5f27bfa1-d033-4b91-9dcf-53c0fcb2a09c is available remotely as 62b6433b9dd77685
su...@google.com <su...@google.com> #55
also the image has different size as before, at least with obs before sonoma i was seeing a cropped image out of the 1280x720 but now i can see it full size on the emulator screen.
In the first fix there is no scale function, I crop and put black everywhere I have no pixels for. When we have the scale function, we crop a smaller image and resize to fill all requested pixels.
dr...@gmail.com <dr...@gmail.com> #56
Tested on M1 Pro 10914596 emulator build and it just hang when launching default camera app with verbose printout
"
DEBUG | getMultiDisplay 0 x 0 y 0 w 1440 h 3120 dpi 560 flag 0 enable 1
DEBUG | getMultiDisplay 0 x 0 y 0 w 1440 h 3120 dpi 560 flag 0 enable 1 (3x)
ERROR | -[MacCamera init:]: cannot add camera capture input device
ERROR | camera_device_open: Unable to initialize camera device.
ERROR | _camera_client_query_connect: Unable to open camera device
"
dr...@gmail.com <dr...@gmail.com> #57
Hi Andi, thank you for reporting this. I think this is a different problem here as 10914596 does not change anything related to opening the device and 10937044 probably missed even more around this case.
Description
I think my issue is unrelated, hence this new bug report.
I am applying a network constrain to my PeriodicWorkRequest:
// ...
constraintsBuilder.setRequiredNetworkType(NetworkType.CONNECTED);
// ...
Constraints constraints = constraintsBuilder.build();
// ...
periodicWorkRequestBuilder.setConstraints(constraints);
// ...
PeriodicWorkRequest = periodicWorkRequestBuilder.build();
The idea is of course that the periodic work will run only if there is network. If there isn't, it will wait until there is, and then perform the work, and the subsequent periodic work will be scheduled after that.
This all works very well based on my own tests. But I have *one* user of an older Android 4.3 device where things break down (there may be others... but only one is reporting it... certainly it is not widespread).
From what I can determine, with a network constraint applied to the periodic work as above, if the periodic work is scheduled to run at time when there is no network, it appears on this user device that it does not run, as expected (because if if did, a "retry" work request would be scheduled by my code, which it isn't).
But it also appears that it NEVER RUNS AGAIN. In other words, the periodic work seems to be enqueued still, but just never runs again. It's as if the restoration of network doesn't kick it into running, and so it never does, ever again.
When this user runs an alternative version of the app where the network constraint is NOT applied to the periodic work (instead applying Constraints.NONE), the periodic work appears to survive the network downtime, and carry on ticking. It does attempt to run without network, which I can tell because a onetime "retry" work is scheduled, which surfaces later.
I have tried to reproduce this on an Android 4.3 emulator to no avail... seems to work as expected. So, this may not be enough information to go on.
It's almost as if CONNECTIVITY_CHANGE is not being received (I assume that WorkManager uses this signal)... or not acted on.
We don't need to add any special permissions or anything to make CONNECTIVITY_CHANGE work on all devices?