This bug was filed from the Socorro interface and is report bp-97b7d2b4-789b-405f-8fb9-6a4422161128. ============================================================= I'm seeing sporadic occurences of this on nightly and aurora, only on Android 5 and 6. Is related to the work done in preparation for using VectorDrawables in the app menu - we only started using AppCompatDrawableManager in Bug 1312114. (Note: once we get to support library 24.2 we'll be able to use AppCompatResources.getDrawable() instead.) Relevant part of the crash stack: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.CharSequence android.content.res.StringBlock.get(int)' on a null object reference at android.content.res.AssetManager.getResourceValue(AssetManager.java:213) at android.content.res.Resources.getValue(Resources.java:1334) at android.content.res.Resources.getDrawable(Resources.java:819) at android.content.res.Resources.getDrawable(Resources.java:799) at android.content.Context.getDrawable(Context.java:403) at android.support.v4.content.ContextCompatApi21.getDrawable(Unknown Source) at android.support.v4.content.ContextCompat.getDrawable(Unknown Source) at android.support.v7.widget.AppCompatDrawableManager.getDrawable(Unknown Source) at android.support.v7.widget.AppCompatDrawableManager.getDrawable(Unknown Source) at org.mozilla.gecko.util.ResourceDrawableUtils.getDrawable(ResourceDrawableUtils.java:34) at org.mozilla.gecko.menu.GeckoMenuItem.getIcon(GeckoMenuItem.java:159)
I should probably look into this soon, but it doesn't look like an immediate priority either, hence P2.
status-firefox52: --- → affected
Priority: -- → P2
I'm not too confident on this one: - The crash leads to native android code (AssetManager.loadResourceValue doesn't load data into mStringBlocks as expected) - And has been experienced by others: https://code.google.com/p/android/issues/detail?id=221193 - And doesn't seem to be specific to AppCompatDrawableManager, OsmAnd fixed their equivalent of this crash by switching to ResourcesCompat, but I don't see any justification for why this would be any better: https://github.com/osmandapp/Osmand/commit/0396fb11ca8bc33be7fa9c8cee1fe1c2e7684de8 One difference I can see is that we can provide a "null" theme to ResourcesCompat, whereas going via AppCompatDrawableManager results in the getTheme() being used, maybe that somehow convinces the native resource loading to work - but as far as I can see we're already using the codepath for a "null" path in Resources.getDrawable?
Looking at crashstats, most of the traces don't even involve AppCompatDrawableManager, i.e this seems to be a generic Android resource loading bug. I see crashes happen using: getResources().getDrawable() in TabsPanelThumbnailView.setImageDrawable() AppCompatImageView.setImageResource() in TabStripItemView.updateFavicon() AppCompatDrawableManager.getDrawable) in GeckoMenuItem.getIcon() Even during layout inflation in CombinedHistoryAdapter.onCreateViewHolder() If this specifically looks worse with 52 then we should maybe reopen (i.e. if we still see this as being significant once 52 is in beta), but right now it looks like it's only visible because of the proportions of nightly/aurora users on affected devices. (Bug 1309821 landed in 52, and adds the --no-version-vectors flag to aapt, so my backup hypothesis is that that breaks resource loading on some devices sometimes - that won't be all too clear until we're in beta.)
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.