NullPointerException on FileProvider Crash reports from Android 8/8.1 with 0.9.0-beta3

[jasonandress]

WARNING: IF YOU IGNORE THIS TEMPLATE, WE'LL IGNORE YOUR ISSUE. YOU MUST FILL THIS IN!

Provide a general summary of the issue.

Your Environment
Plugin version: 0.9.0-beta3
Platform: Android
OS version: 8.1 / 8.0
Device manufacturer / model: Mostly Pixels
Cordova version (cordova -v): 7.0.1
Cordova platform version (cordova platform ls): cordova-android 6.3.0
Plugin config
Ionic Version (if using Ionic)

Cordova CLI: 7.0.1
Gulp version: CLI version 3.9.1
Gulp local: Local version 3.9.1
Ionic Framework Version: 1.3.5
Ionic CLI Version: 1.7.16
Ionic App Lib Version: 0.7.3
OS:
Node Version: v6.11.0

Expected Behavior
Actual Behavior
After introducing version 0.9.0-beta3, I have been getting thousands of crash reports from Google for devices running Android 8.1. and 8.0 (error attached below). I have tested the app on a Samsung 8 running android 8.1 as well as a few emulators, and I haven't noticed any issues.

I've received one report from a user that they are seeing the Android error that reports that my app has crashed in the background.

Steps to Reproduce
Context
Debug logs
This is the error google has been reporting

java.lang.RuntimeException:
at android.app.ActivityThread.installProvider (ActivityThread.java:5868)
at android.app.ActivityThread.installContentProviders (ActivityThread.java:5457)
at android.app.ActivityThread.handleInstallProvider (ActivityThread.java:2936)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1688)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:154)
at android.app.ActivityThread.main (ActivityThread.java:6131)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:776)
Caused by: java.lang.NullPointerException:
at android.support.v4.content.FileProvider.parsePathStrategy (FileProvider.java:591)
at android.support.v4.content.FileProvider.getPathStrategy (FileProvider.java:565)
at android.support.v4.content.FileProvider.attachInfo (FileProvider.java:378)
at android.app.ActivityThread.installProvider (ActivityThread.java:5865)

Source code
This is a simplified version of the code I use to set notifications:

cordova.plugins.notification.local.schedule(
{
	id: 8,
	title: 'Enter your Data',
	text: 'Lets enter your data for today!',
	smallIcon: 'res://icon',
	trigger: {every: {hour: notifAt.getHours(), minute: notifAt.getMinutes()}}
},
function () {
	console.log("Daily Notification set");
},
function(_error){
	$exceptionHandler(_error);
});

[jayseb11]

I am also noticing the same issue. Occurring on devices 8.0 and up.

[Gachapen]

Experiencing the same issue on Android 7.0, 8.0 and 8.1 on multiple devices (Xperia XZ2 Compact, Nokia 8 Sirocco, P10 lite, Xperia XZ1, Mate 10 Pro), using the current master version of this plugin. Not sure what the impact is.

[Gachapen]

Actually, in my case another plugin caused this problem, namely darryncampbell-cordova-plugin-intent. It seems that the provider specification for the FileProvider in the AndroidManifest was incorrect. android:authorities="${applicationId}.provider" should be changed to android:authorities="${applicationId}.fileprovider". Changing this seems to have resolved the issue for me. See the PR for details: darryncampbell/darryncampbell-cordova-plugin-intent#58

I recommend that others with this problem check their generated AndroidManifest.xml for this issue, find which plugin that generates the code for the FileProvider section, and correct it.

[ivanov84]

But in this plugin this code:

cordova-plugin-local-notifications/plugin.xml

Line 105 in 6d1b27f

android:authorities="${applicationId}.provider"

[Gachapen]

True, but that is for de.appplant.cordova.plugin.notification.util.AssetProvider, not for FileProvider. I don't know if the fact that AssetProvider derives from FileProvider can cause any issues, but currently I'm seeing zero crash reports, even when not changing the authorities for AssetProvider in this plugin.

[ivanov84]

@Gachapen I have android:authorities="${applicationId}.provider" also for cordova-plugin-camera but I am not sure that I can change it to android:authorities="${applicationId}.fileprovider" there.

Could you suggest how to test? Except publish to product and see into crash logs?

[Gachapen]

Hm, it's a tricky issue. I wasn't able to reproduce the crash locally, and I have no idea when it happens, so I just made the change, tested that nothing broke, and published a new version. You could do the same, but publish it in the test channel, or do a partial rollout, and see if you get any crash reports. Also, if you build a release version and install it on your phone, you can still see crash reports in Play if you select to see "from all sources".

[ivanov84]

@Gachapen Thanks. I'll try it.

[jasonandress]

Thanks @Gachapen
I also have found one of my other Plugins has the same issue. I'll update it and test to see if that plugin still works with the change.

https://github.com/techaffinity/freshchat-phonegap/blob/15359e95ab1e7815c70108b75a12442fa181f163/plugin.xml#L51

[Gachapen]

I think I discovered what the actual issue is. At least for me it seems to be because two plugins (this, and https://github.com/darryncampbell/darryncampbell-cordova-plugin-intent) both provide different providers through the same authorities (${applicationId}.provider), thus causing a conflict. I think the solution is to have unique identifiers in each plugin.

Can you confirm that you also have two <provider> sections in your manifest with the same authorities?

See more here: darryncampbell/darryncampbell-cordova-plugin-intent#58 (comment)

[jasonandress]

Yes that's the case with me. This plugin had the AssetProvider as ${applicationId}.provider as well as another one of my plugins FileProvider as ${applicationId}.provider.

[ivanov84]

And my plugins add the same lines:
<provider android:authorities="${applicationId}.provider" android:exported="false" android:grantUriPermissions="true" android:name="android.support.v4.content.FileProvider"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/provider_paths" /> </provider>

<provider android:authorities="${applicationId}.provider" android:exported="false" android:grantUriPermissions="true" android:name="de.appplant.cordova.plugin.notification.util.AssetProvider"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/localnotification_provider_paths" /> </provider>

[jasonandress]

Does anyone know the significance of the android:authorities? Does it reference something in the plugin's code or can it be anything with no other impacts? I ask because it seems like ".provider" is something that everyone uses. If it can be anything, can it be unique to this plugin?

[Gachapen]

Yes, it is used in the code with the FileProvoder. See darryncampbell/darryncampbell-cordova-plugin-intent@767134c which does exactly what you suggest, i.e. making it unique. I have yet to test this in out app, but I assume it will solve the issue. I recommend anyone using the intent plugin to test the new version to see if it solves the issue.

[jasonandress]

The thing is I don't use that plugin. The other plugin I use seems to have that code in a compiled SDK because I can't find it in their repo. I wanted to see if we can just change this repo's code. Any suggestions?

[Gachapen]

@jasonandress Yes, you can change this repo's code. You need to do the equivalent of what was done in the commit I linked, i.e. change the provider in plugin.xml and change all uses of it in the code. As far as I can see, only AssetUtil.java uses it in this repo:

cordova-plugin-local-notifications/src/android/notification/util/AssetUtil.java

Line 360 in 6d1b27f

String authority = context.getPackageName() + ".provider";

[ivanov84]

I changed in AssetUtil.java and in plugin.xml provider to LocalNotificationProvider and published in production. Error stoped.

[jasonandress]

@ivanov84 thanks for letting us know. I've done the same but have left it in beta testing for a few days. No errors for me either so far.