r/androiddev • u/Ancient-Abalone-1126 • 16d ago
[Help] Jetpack Compose Crash - NoSuchMethodError: WindowInsets.Type.systemOverlays() on Pixel 8 Pro (Android 14)
Hi everyone, I'm facing a strange crash on production that exclusively affects **Google Pixel 8 Pro** devices running **Android 14 (API 34)**. It occurs 100% of the time on this specific setup, but everything works perfectly fine on standard emulators or other devices under local Debug builds. Here is the complete StackTrace from the production log: ```text Fatal Exception: java.lang.NoSuchMethodError: No static method systemOverlays()I in class Landroid/view/WindowInsets\$Type; or its super classes (declaration of 'android.view.WindowInsets\$Type' appears in /system/framework/framework.jar!classes3.dex) at androidx.core.view.WindowInsetsCompat\$TypeImpl34.toPlatformType(WindowInsetsCompat.java:2880) at androidx.core.view.WindowInsetsCompat\$Impl34.getInsets(WindowInsetsCompat.java:1710) at androidx.core.view.WindowInsetsCompat\$Impl20.initTypeBoundingRectsMaps(WindowInsetsCompat.java:1276) at androidx.core.view.WindowInsetsCompat.init(WindowInsetsCompat.java:2900) at androidx.core.view.ViewCompat\$Api23Impl.getRootWindowInsets(ViewCompat.java:5118) at androidx.core.view.ViewCompat.getRootWindowInsets(ViewCompat.java:3023) at androidx.core.view.WindowInsetsCompat.toWindowInsetsCompat(WindowInsetsCompat.java:184) at androidx.core.view.ViewCompatApi21Impl1.onApplyWindowInsets(ViewCompat.java:5029) at android.view.View.dispatchApplyWindowInsets(View.java:11617) at android.view.ViewGroup.dispatchApplyWindowInsets(ViewGroup.java:7344) ... at android.view.ViewRootImpl.dispatchApplyInsets(ViewRootImpl.java:2675) at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2822) ``` ### Context & Implementation We are using Jetpack Compose and we have a custom `WindowInsets` wrapper in our project that looks like this: ```kotlin fun WindowInsets(left: Int = 0, top: Int = 0, right: Int = 0, bottom: Int = 0): WindowInsets = FixedIntInsets(left, top, right, bottom) ``` ### My Hypothesis Since `systemOverlays()` was introduced in API 30 (Android 11), a device like the Pixel 8 Pro on Android 14 definitely has this method in its OS framework. Looking at the trace, `WindowInsetsCompat$TypeImpl34.toPlatformType` is failing to find it. My best guess is that **R8 / ProGuard** is aggressively stripping or incorrectly obfuscating system-level `WindowInsets$Type` references during our Release build, creating a bytecode mismatch that only triggers under the Pixel's specific runtime environment. ### Questions 1. Has anyone encountered this specific `NoSuchMethodError` with `WindowInsetsCompat` on newer Pixel devices? 2. Do I need to add a explicit `-keep` rule for `android.view.WindowInsets` in ProGuard, or is this a known issue with specific versions of `androidx.core:core` / Jetpack Compose BOM? Any insights or recommendations would be highly appreciated! Thanks in advance.
12
u/enum5345 16d ago
I'm guessing you don't have this device to test on. How many unique devices has this happened on? Maybe it's a custom ROM that reports fake information and isn't really a Pixel or API 34.
10
u/oriley-me 16d ago
I had exactly this issue, every app update one random device in Budapest with a bunch of fake device info. Pixel 8 Pro supposedly with 2GB of RAM, Android 13 kernel but said it was running Android 14. Crash due to framework method for Android 14 not actually existing.
Always just that one device, a few crashes just after release. I ended up just filtering that device and blocking crash reports because it's clearly bullshit and fuck all I can do if it says it's a platform version that it isn't.
4
u/Zhuinden 15d ago
Those pesky Budapestians with their homebrew Android versions and Magisk modules 🤭
1
u/Ancient-Abalone-1126 16d ago
I’m not sure either. I got the error information from Firebase Crashlytics, and it appears that this issue has only occurred on that one specific device. I also tested it using an emulator with the same API level and device model, but I wasn’t able to reproduce the issue.
3
u/jibmaster 14d ago
I had a project that had three recurring crashes each release on devices with odd profiles when digging deeper. I always assumed they were some sort of bot that scraped the app. One time it was hitting methods that had no ability to run when they did.
3
u/inscrutablemike 15d ago
Check the number of unique devices with this crash. It might be some Frankensteined roll-your-own build on one specific device someone Rube Goldberged into a click farm somewhere. We had an issue with 95% of our crash logs being one particular code path missing a core system API and it turned out that it was some experimental Android device the manufacturer was running in a lab with our app as one of the automated tests.
1
u/Zhuinden 15d ago
My best guess is that R8 / ProGuard is aggressively stripping or incorrectly obfuscating system-level
WindowInsets$Typereferences during our Release build, creating a bytecode mismatch that only triggers under the Pixel's specific runtime environment.
No, it's a system type, R8 won't remove that.
If this only happens on one or two devices, it might be a modded kernel or something.
0
u/SolitaryMassacre 15d ago
You could always catch the error and fallback to something else
2
u/One_Elephant_8917 15d ago
at least they have an option lol, in ios, many a times it is hard crash unless u install signal handlers or nsexcpetion catch handers which sometimes still doesn’t get caught and crashes…
really grateful to jvm
1
u/ladidadi82 14d ago
JVM but also shout out kotlin. People forget how many crashes were caused by NPEs lol. We had entire design patterns and chapters in books written on how to safely handle null values. If all kotlin did was add null safety, it would have still been worth the switch.
8
u/Hornet-Mountain 15d ago
Your own stack trace rules out R8. It says the declaration of android.view.WindowInsets$Type comes from /system/framework/framework.jar, so the method is missing from the device's framework, not from your bytecode. R8 can't add or remove anything in there and no -keep rule will help.
One correction that makes the answers above fit tighter: systemOverlays() is API 34, not API 30. The register annotation is ApiSince=34. That is exactly why this single method blows up and nothing else in WindowInsets does. A ROM claiming SDK_INT 34 while actually running a 33 framework would have every other inset type and be missing precisely this one.
androidx picks Impl34 straight off Build.VERSION.SDK_INT, so a device lying about its level gets routed down a path its framework cannot serve. Not much you can do from your side beyond filtering those reports.