'[App] isn't responding' window pops up repeatedly on Quest 3 but not Quest 2. Oculus UE 5.3.2
EDIT 7/2/2025:
Solved by moving the function call
UAudioCaptureAndroid::AndroidAskPermission();from BeginPlay of an actor on app launch, to a more appropriate time. An artifact from a junior developer years ago that only started causing a serious problem in recent weeks for some reason.
Hello,
Our app recently started getting some odd behaviour with the window '[App] isn't responding' popping up. There are two options: 'Close app' and 'Wait'. If you click 'Wait' it pops up again a few seconds later. This doesn't stop happening.
The app is built for both Quest 2 and Quest 3, and this only happens on Quest 3. Apart from some frame rate drops while loading levels, the app runs fine on Quest 3 and has a smooth framerate. So It's difficult to put this on a performance problem.
The UE5 version is 5.3.2 source built from the Oculus fork commit# 6660f12. The Quest 3 is fully up to date. I am really hoping that the Quest 3 does not expect a newer version of UE5 because I do not want to move the project to another engine version.
Is anyone able to help point out what could be causing this? Here is a folder with a log file and recording of the problem.
The following lines in the log file are a clue. Has anyone seen this sort of thing before? It makes no sense that my game thread is blocked. The app is running smoothly. The error appears when I am in our splash screen level with very little happening inside of it.
12:57:14.112 1391 1651 W InputDispatcher: Window 82cef00 KaleidoscopeXR.Caregiver_VR/com.epicgames.unreal.GameActivity (server) is unresponsive: 82cef00 KaleidoscopeXR.Caregiver_VR/com.epicgames.unreal.GameActivity (server) is not responding. Waited 5003ms for FocusEvent(hasFocus=true)
12:57:14.112 1391 1651 W InputDispatcher: Canceling events for 82cef00 KaleidoscopeXR.Caregiver_VR/com.epicgames.unreal.GameActivity (server) because it is unresponsive
12:57:14.120 1391 1651 I WindowManager : ANR in Window{82cef00 u0 KaleidoscopeXR.Caregiver_VR/com.epicgames.unreal.GameActivity}. Reason:Input dispatching timed out (82cef00 KaleidoscopeXR.Caregiver_VR/com.epicgames.unreal.GameActivity (server) is not responding. Waited 5003ms for FocusEvent(hasFocus=true)).
12:57:14.129 1391 10588 D ActivityManager: created ANR temporary file:/data/anr/temp_anr_4492015528561699829.txt
12:57:14.129 1391 10588 I ActivityManager: Collecting stacks for pid 10350 into temporary file temp_anr_4492015528561699829.txt
The error appears even after a factory reset of the Quest 3. Log file in folder.
13:48:11.330 1339 10106 I ActivityManager: Done dumping
13:48:11.351 1339 10106 E ActivityManager: ANR in KaleidoscopeXR.Caregiver_VR (KaleidoscopeXR.Caregiver_VR/com.epicgames.unreal.GameActivity)
13:48:11.351 1339 10106 E ActivityManager: PID: 9600
13:48:11.351 1339 10106 E ActivityManager: Reason: Input dispatching timed out (71a728e KaleidoscopeXR.Caregiver_VR/com.epicgames.unreal.GameActivity (server) is not responding. Waited 5003ms for FocusEvent(hasFocus=true)).
13:48:11.351 1339 10106 E ActivityManager: Parent: KaleidoscopeXR.Caregiver_VR/com.epicgames.unreal.GameActivity
13:48:11.351 1339 10106 E ActivityManager: ErrorId: 6d3d432b-83d8-4df8-8505-22c7e5da2754
13:48:11.351 1339 10106 E ActivityManager: Frozen: false
13:48:11.351 1339 10106 E ActivityManager:
13:48:11.351 1339 10106 E ActivityManager: OomScoreAdj: 0
13:48:11.351 1339 10106 E ActivityManager:
13:48:11.351 1339 10106 E ActivityManager: Process History:
13:48:11.351 1339 10106 E ActivityManager: Entry 0: timestamp: 364592 Setting shouldNotFreeze to: false
13:48:11.351 1339 10106 E ActivityManager: Entry 1: timestamp: 364592 Changing OomScoreAdj from: -10000 to: 1001
13:48:11.351 1339 10106 E ActivityManager: Entry 2: timestamp: 364594 Changing OomScoreAdj from: 1001 to: 905
13:48:11.351 1339 10106 E ActivityManager: Entry 3: timestamp: 364599 Setting shouldNotFreeze to: false
13:48:11.351 1339 10106 E ActivityManager: Entry 4: timestamp: 364599 Changing OomScoreAdj from: 905 to: 1001
13:48:11.351 1339 10106 E ActivityManager: Entry 5: timestamp: 364601 Changing OomScoreAdj from: 1001 to: 905
13:48:11.351 1339 10106 E ActivityManager: Entry 6: timestamp: 364620 Setting shouldNotFreeze to: false
13:48:11.351 1339 10106 E ActivityManager: Entry 7: timestamp: 364620 Changing OomScoreAdj from: 905 to: 1001
13:48:11.351 1339 10106 E ActivityManager: Entry 8: timestamp: 364620 Changing OomScoreAdj from: 1001 to: 905
13:48:11.351 1339 10106 E ActivityManager: Entry 9: timestamp: 364626 Setting shouldNotFreeze to: false
...
13:48:11.351 1339 10106 E ActivityManager: anr_looper_history:
13:48:11.351 1339 10106 E ActivityManager: ----- Output from /proc/pressure/memory -----
13:48:11.351 1339 10106 E ActivityManager: some avg10=2.87 avg60=2.48 avg300=0.67 total=2300514
13:48:11.351 1339 10106 E ActivityManager: full avg10=0.95 avg60=0.92 avg300=0.25 total=912770
13:48:11.351 1339 10106 E ActivityManager: ----- End output from /proc/pressure/memory -----
13:48:11.351 1339 10106 E ActivityManager: ----- Output from /proc/pressure/cpu -----
13:48:11.351 1339 10106 E ActivityManager: some avg10=10.29 avg60=8.49 avg300=5.21 total=30980015
13:48:11.351 1339 10106 E ActivityManager: ----- End output from /proc/pressure/cpu -----
13:48:11.351 1339 10106 E ActivityManager: ----- Output from /proc/pressure/io -----
13:48:11.351 1339 10106 E ActivityManager: some avg10=1.85 avg60=1.11 avg300=0.56 total=4572247
13:48:11.351 1339 10106 E ActivityManager: full avg10=0.46 avg60=0.32 avg300=0.17 total=1820313
13:48:11.351 1339 10106 E ActivityManager: ----- End output from /proc/pressure/io -----
13:48:11.351 1339 10106 E ActivityManager: ----- Output from /proc/swaps -----
13:48:11.351 1339 10106 E ActivityManager: Filename Type Size Used Priority
13:48:11.351 1339 10106 E ActivityManager: /data/vendor/flashswap/swap.dat file 524284 0 5
13:48:11.351 1339 10106 E ActivityManager: /dev/block/zram0 partition 4194300 590336 10
13:48:11.351 1339 10106 E ActivityManager: ----- End output from /proc/swaps -----
13:48:11.351 1339 10106 E ActivityManager:
13:48:11.351 1339 10106 E ActivityManager: CPU Load: 8.22 / 4.75 / 2.18
13:48:11.351 1339 10106 E ActivityManager: CPU usage from 0ms to 6831ms later (2025-06-20 13:48:04.500 to 2025-06-20 13:48:11.330):
13:48:11.351 1339 10106 E ActivityManager: 141% 9600/KaleidoscopeXR.Caregiver_VR: 125% user + 16% kernel / faults: 159530 minor 51 major
13:48:11.351 1339 10106 E ActivityManager: 30% 1721/com.oculus.vrruntimeservice: 25% user + 4.8% kernel / faults: 7279 minor 269 major
13:48:11.351 1339 10106 E ActivityManager: 25% 1076/trackingservice: 20% user + 4.6% kernel / faults: 3498 minor 140 major
13:48:11.351 1339 10106 E ActivityManager: 11% 856/vendor.oculus.hardware.sensors@1.0-service: 6.4% user + 4.9% kernel / faults: 23 minor 1 major
13:48:11.351 1339 10106 E ActivityManager: 11% 2227/com.oculus.vrshell: 6.8% user + 4.5% kernel / faults: 3614 minor 216 major
13:48:11.351 1339 10106 E ActivityManager: 10% 1339/system_server: 5.7% user + 4.3% kernel / faults: 4863 minor 312 major
13:48:11.351 1339 10106 E ActivityManager: 7% 885/audioserver: 5.8% user + 1.1% kernel / faults: 4 major
13:48:11.351 1339 10106 E ActivityManager: 4.6% 826/android.hardware.audio.service: 2.1% user + 2.4% kernel
13:48:11.351 1339 10106 E ActivityManager: 2.4% 377/kgsl_hwsched: 0% user + 2.4% kernel
13:48:11.351 1339 10106 E ActivityManager: 2.3% 1086/syncboss:spi_th: 0% user + 2.3% kernel
13:48:11.351 1339 10106 E ActivityManager: 50% TOTAL: 36% user + 11% kernel + 0.6% iowait + 2.1% irq + 0.1% softirq
13:48:11.351 1339 10106 E ActivityManager: CPU usage from 227ms to 567ms later (2025-06-20 13:48:04.727 to 2025-06-20 13:48:05.067):
13:48:11.351 1339 10106 E ActivityManager: 175% 9600/KaleidoscopeXR.Caregiver_VR: 140% user + 35% kernel / faults: 3015 minor
13:48:11.351 1339 10106 E ActivityManager: 92% 9605/Signal Catcher: 92% user + 0% kernel
so on...
13:48:11.353 1339 10106 D ActivityManager: Completed ANR of KaleidoscopeXR.Caregiver_VR in 6907ms, latency 0ms
I asked Claude and this is what it said:
I have a VR application being developed in Unreal Engine 5 for Meta Quest. It's called Caregiver VR. When I run the app in the Meta Quest 3, a window keeps popping up that says 'Caregiver VR isn't responding' and it gives me the option to close or wait. I am attaching a log file, can you look through it and tell me if you can see any reason for this happening?
Edit
Looking through your log file, I can see several indicators that point to why you're getting the "Caregiver VR isn't responding" (ANR - Application Not Responding) dialog:
Key Issues Identified:
1. Main Thread Blocking
The most telling entry is:
17:35:01.099 1245 1269 W WindowOnBackDispatcher: sendCancelIfRunning: isInProgress=falsecallback=android.view.ViewRootImpl$$ExternalSyntheticLambda17@46f0fa4
17:35:01.099 1245 1269 D CoreBackPreview: Window{7f72bf8 u0 Application Not Responding: KaleidoscopeXR.Caregiver_VR}: Setting back callback null
This shows the system has detected your app as not responding and is creating the ANR dialog.
2. Performance Issues
From the VrApi performance logs:
17:35:01.008 25941 26091 I VrApi: FPS=51/120,Prd=44ms,Tear=0,Early=67,Stale=34
Your app is only achieving 51 FPS instead of the target 120 FPS
Frame period is 44ms (should be ~8.33ms for 120Hz)
34 stale frames indicate the app isn't keeping up with the display refresh rate
3. Memory Pressure
17:35:00.554 25941 25986 D UE: memstat: VmRSS: 1285024 kB
17:35:00.554 25941 25986 D UE: memstat: VmSwap: 14892 kB
Your app is using about 1.25GB of RAM and has started swapping memory, which can cause performance issues.
4. GPU Performance
17:35:01.008 25941 26091 I VrApi: GPU%=0.96,CPU%=0.90
Both GPU and CPU utilization are very high (96% and 90% respectively), indicating performance bottlenecks.
Recommendations:
Optimize Rendering Performance
Reduce polygon count or LOD complexity
Optimize textures and materials
Check for expensive shaders or effects
Use Unreal's VR performance profiling tools
Memory Optimization
Reduce texture sizes where possible
Implement proper LOD systems
Check for memory leaks in blueprints or C++ code
Use texture streaming
Main Thread Optimization
Move heavy computations off the main thread
Avoid blocking operations in Tick functions
Use async loading for assets
Check for infinite loops or expensive operations in blueprints
VR-Specific Optimizations
Enable Forward Rendering
Use Mobile HDR rendering pipeline
Implement foveated rendering if available
Optimize draw calls and reduce overdraw
The ANR is likely occurring because your main thread is being blocked by performance bottlenecks, preventing the app from responding to system events within Android's timeout period (typically 5 seconds).
okay but this problem doesn't happen in Quest 2 which is less powerful than Quest 3.
Edit
That's a very important detail that changes the analysis significantly. If your app runs fine on Quest 2 but has ANR issues on Quest 3, this suggests a Quest 3-specific compatibility issue rather than general performance problems.
Looking at the logs with this context, here are the most likely Quest 3-specific causes:
Quest 3-Specific Issues:
1. Resolution/Display Differences
Quest 3 has a higher resolution than Quest 2:
Quest 2: 1832×1920 per eye
Quest 3: 2064×2208 per eye
From your logs:
17:34:59.857 2500 3182 I [SEO] LayerSwapChainResource: LayerSwapChainResource width(4128), height(2208), swap chain length(3), mips(4)
The 4128×2208 resolution indicates Quest 3's higher resolution is being used, which could be causing:
Unexpected memory usage spikes
Rendering pipeline issues not present at Quest 2's lower resolution
UE5 scaling problems with the new resolution
2. Pancake Lens Rendering Pipeline
Quest 3 uses pancake lenses vs Quest 2's fresnel lenses, which can affect:
Distortion correction algorithms
Rendering optimizations that worked on Quest 2
Foveated rendering implementations
3. Mixed Reality Features
Quest 3 has passthrough cameras and MR capabilities that Quest 2 lacks:
17:35:00.254 1086 25155 I MRSS: MIXEDREALITY: MrSystemService: FramesetTelemetry
17:35:00.372 2651 25206 I [CT]: MIXEDREALITY: PassthroughApiManager: GetUpdatedLayerState
Even if you're not using MR features, the system might be:
Running additional background processes
Allocating memory for MR systems
Interfering with your app's rendering context
4. Snapdragon XR2 Gen 2 Differences
Quest 3's newer chipset might have:
Different GPU driver behavior
Changed memory management
Different thermal throttling patterns
Updated Vulkan/OpenGL implementations
Debugging Recommendations:
Check UE5 Quest 3 Settings
Verify your project is using the latest Meta XR SDK
Check if there are Quest 3-specific rendering settings
Look for resolution scaling options in VR settings
Test Resolution Scaling
Try forcing a lower render resolution to match Quest 2
Use r.ScreenPercentage console command to test different scales
Update Dependencies
Ensure you're using the latest UE5 version with Quest 3 support
Update Meta XR SDK to the newest version
Check for any Quest 3-specific patches or hotfixes
Memory Investigation
Compare memory usage patterns between Quest 2 and Quest 3
The higher resolution might be pushing you over a memory threshold
Disable MR Features
Try explicitly disabling any mixed reality or passthrough features
Check if the issue persists with MR services disabled
The fact that it works on the less powerful Quest 2 strongly suggests this is a compatibility/configuration issue rather than a performance bottleneck.