Fatal Exception: ResourcesNotFoundException

[DimaDDM]

Crash when app trying init Toasty.warning ToastyUtils.getDrawable(context, drawable.ic_error_outline_white_48dp)

I never see this issue before but after building as App bundle it's happens.

[SG57]

I'm also seeing a similar ResourceNotFoundException after building as app bundle, but only impacting certain devices?

android.content.res.Resources$NotFoundException: Resource ID #0x7f0801a9

Coming from ToastyUtils.tint9PatchDrawableFrame, specifically the line getDrawable(context, R.drawable.toast_frame).

Doesn't reproduce on Pixel, but it does on a Samsung Galaxy Note 9 (SM-N960F).

I haven't tried building as APK to see if it reproduces, but it is convenient just as I switch to app bundles this starts happening. Will investigate, please update if you find anything.

EDIT

To add, the error is happening in an onActivityResult event but I'm unsure if it's limited to there. Perhaps the Activity as the context for the getDrawable call is not available for use during this event? That or the drawable resources are simply not included due to the app bundling mechanism, who knows.

[GrenderG]

I haven't used App bundles yet. Any help debugging this will be much appreciated! And of course, PRs are very welcomed.

I'll try to look into this too.

EDIT: After searching for this issue in StackOverflow seems like more people are having ResourcesNotFoundException in their apps using App bundles. Maybe it can be an Android related bug?

[SG57]

Looks like it's most likely due to users side-loading an APK?

https://stackoverflow.com/questions/52469914/app-sometimes-crashes-with-resourcesnotfoundexception-after-switching-to-androi

With App bundling Google intentionally splits APKs and if a user when side-loading doesn't do it correctly then it makes sense it'll fail. If this were a wider-spread issue I feel like I'd be seeing more reports than just 1 from 1 user so far.

[DimaDDM]

I still have some some issues on due to the use of app bundles. But this bug more often. Now i'm using workaround like this. It's work.

Can you make safe method? For example if resources not found just show toast with same settings but without icon. Thanks.

[GrenderG]

@SG57 That makes sense.

@DimaDDM I'm not sure if I should add that check inside the library, I think it's better to let the developer handle these issues. But I'll think about it.

[mueller-ma]

I still get a lot of crashes, even with version 1.4.2.

Fatal Exception: android.content.res.Resources$NotFoundException: Resource ID #0xffff5722
       at android.content.res.ResourcesImpl.getValue(ResourcesImpl.java:216)
       at android.content.res.Resources.getColor(Resources.java:961)
       at android.content.Context.getColor(Context.java:610)
       at androidx.core.content.ContextCompat.getColor(ContextCompat.java:523)
       at es.dmoral.toasty.ToastyUtils.getColor(ToastyUtils.java:59)
       at es.dmoral.toasty.Toasty.custom(Toasty.java:275)

@GrenderG Can you please reopen this issue?

I'm not sure if I should add that check inside the library, I think it's better to let the developer handle these issues. But I'll think about it.

I'd like to have this in the lib itself. Otherwise I would have to check for this exception whenever I show a toast. I agree it's not the best solution, but I prefer having a toast w/o an icon instead of a crash.

[mueller-ma]

I guess I found the issue. Please have a look at the stacktrace. Toasty tries to get the resource with ID #0xffff5722:

E/AndroidRuntime(10775): FATAL EXCEPTION: main
E/AndroidRuntime(10775): Process: org.openhab.habdroid.beta, PID: 10775
E/AndroidRuntime(10775): android.content.res.Resources$NotFoundException: Resource ID #0xffff5722
E/AndroidRuntime(10775):    at android.content.res.Resources.getValue(Resources.java:1542)
E/AndroidRuntime(10775):    at android.content.res.Resources.getColor(Resources.java:1184)
E/AndroidRuntime(10775):    at androidx.core.content.ContextCompat.getColor(ContextCompat.java:525)
E/AndroidRuntime(10775):    at es.dmoral.toasty.ToastyUtils.getColor(ToastyUtils.java:59)
E/AndroidRuntime(10775):    at es.dmoral.toasty.Toasty.custom(Toasty.java:275)
E/AndroidRuntime(10775):    at org.openhab.habdroid.core.VoiceService.lambda$showToast$0$VoiceService(VoiceService.java:96)
E/AndroidRuntime(10775):    at org.openhab.habdroid.core.-$$Lambda$VoiceService$vLaZu2FasChqZZb8OLY6AABbZ_s.run(lambda)
E/AndroidRuntime(10775):    at android.os.Handler.handleCallback(Handler.java:739)
E/AndroidRuntime(10775):    at android.os.Handler.dispatchMessage(Handler.java:95)
E/AndroidRuntime(10775):    at android.os.Looper.loop(Looper.java:135)
E/AndroidRuntime(10775):    at android.app.ActivityThread.main(ActivityThread.java:5910)
E/AndroidRuntime(10775):    at java.lang.reflect.Method.invoke(Native Method)
E/AndroidRuntime(10775):    at java.lang.reflect.Method.invoke(Method.java:372)
E/AndroidRuntime(10775):    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1405)
E/AndroidRuntime(10775):    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1200)

Here's the code calling Toasty: https://github.com/openhab/openhab-android/blob/master/mobile/src/main/java/org/openhab/habdroid/core/VoiceService.java#L97 It uses the color openhab_orange: https://github.com/openhab/openhab-android/blob/master/mobile/src/main/res/values/colors.xml#L11 The color code of this color is #ff5722, the same as the ID of the resource. So somewhere @ColorInt int is used as @ColorRes int.

Toast#custom() is overloaded, most of them take colors as res, but one takes them as int: https://github.com/GrenderG/Toasty/blob/master/toasty/src/main/java/es/dmoral/toasty/Toasty.java#L288-L299 Many Android functions take "messages" as string res or as char sequence, so people are used to this. However if they just swap string res with a char sequence in custom(), they also have to change color res to color int, but they don't. I suggest to rename this custom() https://github.com/GrenderG/Toasty/blob/master/toasty/src/main/java/es/dmoral/toasty/Toasty.java#L297 to customResolvedResources() and add a note to the changelog. And I also suggest to catch the NotFoundException and re-throw it with a hint to this issue.

[prakashshuklahub]

After reading all comments , i plan to use custom() message with try block having custom with icon and catch block custom without icon.

App will show toast with or without icon and crash will be prevented.

I have 5 crashes of ResourceNotFound Exception Toasty in 3 days and my active users is 5000. its 0.1%-0.2%

[harmeetsingh-work]

Was facing the same issue that Resource NotFoundException.

Seems in my case I was getting on Android 11+.

And no impact when doing split false, but what I observed is it's due to shrinkResources true.

So, when I tried:

<?xml version="1.0" encoding="utf-8"?>
<resources xmlns:tools="http://schemas.android.com/tools"
    tools:keep="@drawable/ic_check_white_24dp" />

Then there is no issue.

Ref: https://developer.android.com/studio/build/shrink-code#shrink-resources

[DimaDDM]

Oh shit, here we go again...

[harmeetsingh-work]

Seems like all the library drawable resources have to be added to tools:keep.

[1selindursun]

"This is almost certainly users sharing (sideloading) the app, either via P2P sharing programs, or uploading the APK to the web then other users downloading and installing from the web.

People used to dealing with non Android App Bundle apps just transfer and share the main APK. But your App bundle app has lots of "split APKs" for things like the resources, that is how the size saving happens. You can read all about this process on the help page. If a user installs the main APK without installing the right split APKs, then a "Resources Not found" crash will occur the first time the app tries to load a resource.

If you want to support users sideloading your app and just the main APK you could try to detect this situation and display a message to the user (without using any resources) that says "Please install from Google Play". Or you could just decide you aren't going to support users who share APKs in this way.

I suspect in the long run the websites and P2P sharing programs will get better at sharing such APKs properly, so I wouldn't spend too long worrying about it.

If you see this happening far more frequently on lower Android versions, this isn't probably due to a bug in lower Android versions. Instead, it is probably because in countries where users commonly P2P share apps (eg India) users also are far more likely to be on older version phones."

https://stackoverflow.com/a/53082301