2

It started to happen out of the blue a couple of months ago. Android 10 only.

After the user upgrades to a new version of our app, a crash happens on launch.

The crash is only observed once for a given user. So we think the crash happens right after the upgrade to the new build. It is the new build that crashes (not the old one).

This is an example of a crash.

Fatal Exception: android.app.RemoteServiceException: Bad notification(tag=null, id=30) posted from package yo.app, 
crashing app(uid=10613, pid=16365): 
Couldn't inflate contentViewsandroid.view.InflateException: Binary XML file line #19 in yo.app:layout/sky_eraser_main: 
Binary XML file line #19 in yo.app:layout/sky_eraser_main: Error inflating class androidx.appcompat.widget.Toolbar
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2052)
       at android.os.Handler.dispatchMessage(Handler.java:107)
       at android.os.Looper.loop(Looper.java:214)
       at android.app.ActivityThread.main(ActivityThread.java:7710)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:516)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:950)

The crashes look different from build to build. But the pattern is the same.

Let me transcribe what is happening in our opinion.

There is an ongoing notification (id=30) displaying the temperature (we are making a weather app). The notification is not able to post because of a crash while inflating its RemoteViews layout.

It seems that the original layout is substituted by another, completely unrelated layout (sky_eraser_main used in another place of our app). The wrong layout is different from build to build. It looks as though integer layout-ids are getting mixed up. Could it be the result of some weird R8 optimisation?

Unfortunately, we are not able to reproduce the crash locally.

Do you have an idea how to tackle these crashes?

The context

  • Target SDK: 30
  • Deployed as Android app bundle.
  • minifyEnabled = true
  • This is a kotlin multiplatform project.
Pavel
  • 2,610
  • 3
  • 31
  • 50

2 Answers2

1

From what you've been explaining looks like the resource references got updated as the app launches. This guy has the same problem

Essentially, the R class is an autogenerated class by the whole Android Studio build system that gets autogenerated whenever you add, remove and edit resource files. At the end of the day, each field of the "final" R classes (drawable, id, layout, etc.) hold an int value. And for some dark unknown reasons those references are getting updated at the time you first launch the app after an update on Android 10, (and very probably in Android 11 or some other vendor-dependant implementations of Android)

And as per the comment section in his answer (100+) votes doesn't seem to have a fix. I would try to try-catch the inflation of the layout and abort the notification if I manage to catch any exceptions.

Another approach would be to delay the launch of the notification using something like WorkManager to ensure that the references got updated by the time the NotifyWork kicks in

Some random IT boy
  • 7,569
  • 2
  • 21
  • 47
  • Hi! Sorry for the delay. Thank you so much for the detailed post. 1. Unfortunately try/catch would not do the trick because the crash is happening in remote-views internals. Not inside RemoteViews() constructor or notificationManager.notify() 2. The notification is posted approximately in 1 second after the Application launch. I wonder how long do we have to wait for the references to finish the update. Thank you for at least making me think in these directions. Unless someone finds a better way out, the bounty is going to be yours. – Pavel Jan 19 '21 at 14:48
  • I am so sorry to not provide you with a concise answer so don't hesitate to give the bounty to somebody else that is more helpful. **It's a dirty workaround** but you can try inflating the layout right before creating the notification and if that doesn't throw then trigger the _real_ notification. I suggest you use WorkManager or AlarmManager to schedule the notification _even a little bit more further_ Im sorry. – Some random IT boy Jan 19 '21 at 21:38
  • Thank you so much for the help. It's a solid idea to check layout inflation before dispatching the notification. If we to manage to fix the crash I'll let you know. – Pavel Jan 23 '21 at 08:44
  • Is this an open source project? If it is I could try cloning it and checking some other stuff now as for this answer is not by any means a complete answer – Some random IT boy Jan 23 '21 at 10:31
  • 1
    Thank you so much, you are awesome :) This is YoWindow Weather app. It's a commercial project. I don't mind sharing the code with you. Right now it's a complicated task to launch the project in Android Studio from scratch. I don't want you to spend time on this. I hope we can make it on our on. – Pavel Jan 23 '21 at 18:21
0

You may want to explicitly keep the whole class yo.app.R:

-keepattributes InnerClasses

-keep class yo.app.R
-keep class yo.app.R$* {
    <fields>;
}
Martin Zeitler
  • 1
  • 19
  • 155
  • 216