Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARM64 Build crashes on startup #43

Open
KilliKrate opened this issue Dec 23, 2023 · 2 comments
Open

ARM64 Build crashes on startup #43

KilliKrate opened this issue Dec 23, 2023 · 2 comments
Assignees

Comments

@KilliKrate
Copy link

I've recently had problems building my Ubiq project for standalone VR use using ARM64. I've built the project before using ARMv7 with no issues, but with ARM64 the project seems to crash as soon as you enter the game, right after the "made with Unity" splash-screen.

After plenty of debugging I've seem to hit a dead end, so I tried building the Start Here sample with ARM64 to see if even the original sample has this problem, and in my case it has. Here's the steps to reproduce my scenario:

  • Using Unity version 2022.3.10f1
  • Create a fresh Unity project using the 3D preset
  • Install the Ubiq package from the package manager using the git url
  • Import the samples and open the Start Here scene
  • Open the build settings, switch to Android
  • Add the open scene to the "Scenes in Build" section
  • Go to Project Settings > Player > Other settings
  • Select "linear" color space
  • Change the scripting backend to IL2CPP
  • Untick ARMv7 and tick ARM64
  • Untick "Auto Graphics API" and remove Vulkan (keep OpenGLES3)
  • Go to Project Settings > XR Plug-in Management and select Oculus under the Android tab
  • Build and sideload onto a Quest 2 headset

If you try and keep Vulkan as your preferred Graphics API you just get an infinite black loading screen. The build seems to crash most of the time (sometimes it loads unexplainably with no issues) and adb logcat reports a Vulkan-related problem if you use that, but if you switch to OpenGLES3 you just get a crash due to a null-pointer dereference (which I have no idea how to debug).

My biggest concern is that Meta only supports ARM64 applications on the store, but more importantly this issue prevents me from building with OpenXR, which is needed to create a build that supports the first Quest headset. I'd be very glad if you tried to reproduce this and tell me your results (even with a different Unity version, since it shouldn't make a difference?)

@bnco-dev
Copy link
Contributor

bnco-dev commented Jan 8, 2024

Hi @KilliKrate. Thanks for the detailed report, we're seeing the same. It seems like the issue arises from one of our dependencies, Unity's WebRTC implementation (Unity-Technologies/com.unity.webrtc#437). Unfortunately it does not seem to be high priority for them and has been around a few years.

Falling back to our old dotnet WebRTC implementation would solve the issue. But it's a bit limited by comparison, and a lot slower.

A few users in that thread seem to have had some luck messing with the Minify options in Project Settings > Player > Publishing Settings. I'll give it a go when I have some time to see if it makes any difference.

@bnco-dev bnco-dev self-assigned this Jan 8, 2024
@bnco-dev
Copy link
Contributor

Addressed in 2ca2da6. Workaround in v1.0.0-pre.3.

After a lot of digging, it seems like the crash arises from the Vulkan init hooks added to com.unity.webrtc in version v2.4.0-exp.7. Perhaps Oculus' OpenXR compatibility package also hooks into the same event. In the end I've rebuilt the android native plugin in com.unity.webrtc with these hooks stripped out. I've set it up as a new UPM package for Ubiq to pull in here.

This now works okay, but video streaming will probably no longer work. I also ran into another issue while working on this (#49), so we're currently falling back to the old dotnet WebRTC implementation on Android. Hopefully this works for now (we can build and get VOIP), but this will need some more attention over the next few months.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants