Status Update
Comments
ap...@google.com <ap...@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.
ap...@google.com <ap...@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?
ap...@google.com <ap...@google.com> #4
We have quite some crashes like this:
product_name="AndroidEmulator" AND crash.Reason="EXC_BAD_INSTRUCTION / 0x00000001" AND cpu.Architecture="arm64"
ap...@google.com <ap...@google.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
ap...@google.com <ap...@google.com> #6
I suspect EXC_BAD_INSTRUCTION
happens in vImageRotate90_ARGB8888
and vImageScale_ARGB8888
which are used by webcam on MacOS.
ap...@google.com <ap...@google.com> #7
ap...@google.com <ap...@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 (
ap...@google.com <ap...@google.com> #9
ap...@google.com <ap...@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.
ap...@google.com <ap...@google.com> #11
ap...@google.com <ap...@google.com> #12
ap...@google.com <ap...@google.com> #13
ap...@google.com <ap...@google.com> #14
rforzani22 and treblew2017, I shared a Google Drive link with you, see your email.
na...@google.com <na...@google.com> #15
da...@google.com <da...@google.com> #16
lechun.sk, I shared with you.
sa...@google.com <sa...@google.com> #17
na...@google.com <na...@google.com> #18
lechun.sk, this is unexpected. Do you mind uploading a crash report and sharing its id?
Description
Component used: Lifecycle
Version used: 2.6.0-alpha01
Until feature requests such as b/146802533 are released, Gradle does not do any enforcement that Lifecycle artifacts are of the same version (i.e., you could mix and match
lifecycle-common:2.6.0-alpha01
withlifecycle-runtime:2.5.1
).Gradle supports constraints , which ensure that upgrading a transitive dependency will also upgrade other dependencies.
We should manually add two way constraints, similarly to what was done for Paging in b/235256201 , to the various lifecycle artifacts, which will help Gradle enforce the same version policy we intend.
The pairs of artifacts we should add constraints to should match the dependencies we have right now, which should mean the list looks something like: