Kotlin, Android, Java, or what? I'm submitting an ...

# android

[MarkRS]

Kotlin, Android, Java, or what?
I'm submitting an updated APK to the Google Store to comply with their "keep up with the SDK" policy. I've only updated the SDK (from 33 to 34, and the billing client needed updating to 6.0.1 to keep up) but I'm getting crashes, on just two devices out of the who-knows-how-many devices they test.
The stack trace puts the problem right at the beginning of the main screen onStart method and seems to show there's a crash way down in androidx somewhere. Despite including a mapping file it doesn't seem to be de-obfuscated.
Any clues how I can work out what is going on? (Stack trace in 🧵)

[MarkRS]

Exception java.lang.NullPointerException:
  at m8.e.getAWidth (MobileManege:3)
  at k8.d.j (MobileManege:9)
  at a8.b.e1 (MobileManege:154)
  at androidx.fragment.app.Fragment.H1 (MobileManege:20)
  at androidx.fragment.app.c0.f (MobileManege:199)
  at androidx.fragment.app.c0.m (MobileManege:125)
  at androidx.fragment.app.d0.t (MobileManege:31)
  at androidx.fragment.app.w.T0 (MobileManege:28)
  at androidx.fragment.app.w.S (MobileManege:10)
  at androidx.fragment.app.w.x (MobileManege:12)
  at androidx.fragment.app.m.c (MobileManege:5)
  at androidx.fragment.app.j.onStart (MobileManege:21)
  at androidx.appcompat.app.c.onStart (MobileManege:1)
  at uk.co.goodunlimited.mobilemanege.screens.main.MainScreen.onStart (MobileManege:1)
  at android.app.Instrumentation.callActivityOnStart (Instrumentation.java:1510)
  at androidx.test.runner.MonitoringInstrumentation.callActivityOnStart (MonitoringInstrumentation.java:2)
  at android.app.Activity.performStart (Activity.java:8315)
  at android.app.ActivityThread.handleStartActivity (ActivityThread.java:3701)
  at android.app.servertransaction.TransactionExecutor.performLifecycleSequence (TransactionExecutor.java:221)
  at android.app.servertransaction.TransactionExecutor.cycleToPath (TransactionExecutor.java:201)
  at android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:173)
  at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:97)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2308)
  at android.os.Handler.dispatchMessage (Handler.java:106)
  at android.os.Looper.loopOnce (Looper.java:201)
  at android.os.Looper.loop (Looper.java:288)
  at android.app.ActivityThread.main (ActivityThread.java:7898)
  at java.lang.reflect.Method.invoke
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:548)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:936

[Skaldebane]

does this only happen on sdk 34 devices? maybe try also updating other libraries as well? (like androidx activity etc..) and see if that persists.

[Chrimaeon]

If it is a release build and this is the obfuscated stacktrace you should have a mapping.txt file in the release build folder that you can use to deobfuscate the stacktrace with Proguard Retrace.

[MarkRS]

Hi Christian. Thanks, yes, as I said, I have uploaded the mapping file, and used it locally, this is still what I get.
@Skaldebane, It actually occurs in the testing on an SDK33 device (google Pixel 5 64-bit only) and an SDK11 device (google Pixel 5). Both of them 1080x2340 screens, but since I can't see the other "devices" they tested on I don't know if that's significant or not.

[gildor]

Crash is on at m8.e.getAWidth which is code of you app or library, not somewhere else

[MarkRS]

That's what I thought @gildor, but AS doesn't find that text anywhere in my code...
I'll look harder 😞

[gildor]

you should use retrace to get actual name of the class
Christian pointed out, it's obfuscated names of the classes and you need mapping file to de-opfuscate it
See https://developer.android.com/tools/retrace

[Skaldebane]

if you've uploaded the mapping file to Google Play / Firebase, they should normally deobfuscate the stack trace for you, but if that doesn't work for some reason you'll have to use retrace

[MarkRS]

Thanks @Skaldebane. I didn't know about retrace, that's helpful.
However, it's (finally) showing me the deobfuscated trace so I can at least track what it's complaining about now.
It looks like a new release can carry forward the mapping file from the previous release, which, of course, doesn't work.

[gildor]

You should use AAB with a bundled mapping file and you shouldn't have problems with obfuscation

[MarkRS]

I haven't gone to AAB because my app often needs multiple languages loaded at the same time and it seemed to me that was problematic. With an APK I can insist on loading them all, can I do that with an AAB?

[gildor]

No problem at all, you can disable split by languages if you want

[jairajesh91]

Hello Mark, Are you facing this exception only in the release build?

[MarkRS]

Hi @jairajesh91, that's certainly where I'm seeing it, but "only" because that's the build I'm having to focus on. I'm confused because I didn't see it previously on development builds, but I've been away from this project for a while so I'm not sure if this is due to changes in the environment.
I have now fixed this. I tracked it down to constructors for classes created by incoming serialisation. They were upset by statements of the kind "classvar2 = classParam.toString()", ie, although "classParam" was a required constructor somehow it was managing to be null during the test and therefore failed. I changed the code to check the parameter wasn't empty, although I'm not sure how it could be. I perhaps hadn't excluded the case where the device didn't have access to the Google Play Store.