0

I'm really new to android development, and I just got started with React Native.

I'm using two npm packages that both make use of FileProvider.

First one:

<provider
  android:name="android.support.v4.content.FileProvider"
  android:authorities="com.reactlibrary.provider"
  android:exported="false"
  android:grantUriPermissions="true">
    <meta-data
      android:name="android.support.FILE_PROVIDER_PATHS"
      android:resource="@xml/filepaths" />
</provider>

And second one:

<provider>
  android:name="android.support.v4.content.FileProvider"
  android:authorities="com.imagepicker.provider"
  android:exported="false"
  android:grantUriPermissions="true">
  <meta-data
    android:name="android.support.FILE_PROVIDER_PATHS"
    android:resource="@xml/provider_paths" />
</provider>

and upon invoking an action that requires FileProvider I receive an error:

--------- beginning of crash
06-23 11:30:30.879 32664 32664 E AndroidRuntime: FATAL EXCEPTION: main
06-23 11:30:30.879 32664 32664 E AndroidRuntime: Process: com.swipes, PID: 32664
06-23 11:30:30.879 32664 32664 E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke virtual method 'android.content.res.XmlResourceParser android.content.pm.PackageItemInfo.loadXmlMetaData(android.content.pm.PackageManager, java.lang.String)' on a null object reference
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at android.support.v4.content.FileProvider.parsePathStrategy(FileProvider.java:583)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at android.support.v4.content.FileProvider.getPathStrategy(FileProvider.java:557)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at android.support.v4.content.FileProvider.getUriForFile(FileProvider.java:399)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at com.reactlibrary.RNReactNativeDocViewerModule$FileDownloaderAsyncTask.onPostExecute(RNReactNativeDocViewerModule.java:213)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at com.reactlibrary.RNReactNativeDocViewerModule$FileDownloaderAsyncTask.onPostExecute(RNReactNativeDocViewerModule.java:176)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at android.os.AsyncTask.finish(AsyncTask.java:667)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at android.os.AsyncTask.-wrap1(AsyncTask.java)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:684)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:102)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:154)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at android.app.ActivityThread.main(ActivityThread.java:6121)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:889)
06-23 11:30:30.879 32664 32664 E AndroidRuntime:        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:779)

How could I solve this?

Edit

I tried creating a new class for FileProvider, but it still results in the same error. Here's my new code

<provider
  android:name=".FileProviderClass"
  android:authorities="com.reactlibrary.provider"
  android:exported="false"
  android:grantUriPermissions="true">
    <meta-data
      android:name="android.support.FILE_PROVIDER_PATHS"
      android:resource="@xml/filepaths" />
</provider>

and The Class

package com.reactlibrary;

public class FileProviderClass extends android.support.v4.content.FileProvider {
} 
iremlopsum
  • 187
  • 3
  • 13

1 Answers1

0

I'm using two npm packages that both make use of FileProvider

That will not work without some Java and manifest changes.

and upon invoking an action that requires FileProvider I receive an error

You only have one FileProvider. Which of the two "won", I can't say. But this error is coming from a request to create a Uri for the other one.

The simplest solution is to replace one of those npm packages with something else.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • I'm fine with making changes to Java and manifest files to be honest. I'll just clone the repo and use it locally, maintaining it myself. And I can't really use another npm package because these are the only ones that do what I need. Can you guide me towards a resource or information, how to make this work though? – iremlopsum Jun 23 '17 at 19:22
  • @iremlopsum: I haven't worked with React Native, so I don't know all the details of working with their modules. In an ordinary Java-centric Android app, in whichever library that you fork, create a do-nothing subclass of `FileProvider`, then modify the `` element to point to it, instead of pointing directly to `FileProvider`. This allows both `` elements to go into the manifest. [According to stkent](https://stackoverflow.com/q/43175014/115145), `FileProvider` will support both authority strings from the two separate `` elements. – CommonsWare Jun 23 '17 at 19:26
  • I assume that react-native itself has very little to do with it and it is an Android issue. I tried your solution and edited my original question with the code. It still doesn't work – iremlopsum Jun 23 '17 at 19:59
  • @iremlopsum: With your revised code, are you crashing from either provider? Or does one work and the other not? If the latter, which one is working? – CommonsWare Jun 23 '17 at 20:25
  • One works, the other one doesn't. Same was before revising the code as well. – iremlopsum Jun 23 '17 at 20:27
  • @iremlopsum: You're sure that you're picking up your revised code? You can use an app like [this one](https://play.google.com/store/apps/details?id=com.majeur.applicationsinfo) to inspect the installed copy of your app and see the providers. – CommonsWare Jun 23 '17 at 20:35
  • Checked it with the app. The revised code gets picked up. One of the providers is android.support.v4.content.FileProvider and the other one is com.reactlibrary.FileProviderClass – iremlopsum Jun 23 '17 at 20:40
  • @iremlopsum: The error that you are getting is because the authority string being passed into `getUriForFile()` is not matching the authority string of any provider on the device. In your original setup, there can be only one `` for `android.support.v4.content.FileProvider`. I don't know how the React Native build process reconciles that (in normal Android development, the build should have failed). Now, though, if both providers are there and both authority strings look good... the only thing I can think of is a bug in whoever is calling `getUriForFile()`, passing the wrong string. – CommonsWare Jun 23 '17 at 20:51
  • Hmm, I see. So, the both npm packages work independently. If I remove one and use only the other and vice versa, the remaining library works with no problems, so I assume it isn't faulty code with getUriForFile(). But just to understand the root of the issue then I can have only one provider that uses FileProvider? – iremlopsum Jun 23 '17 at 20:58
  • @iremlopsum: You can only have one `` element whose `android:name` is `android.support.v4.content.FileProvider`. That is where stkent's trick of a subclass is supposed to help, as Android considers `android.support.v4.content.FileProvider` and `com.reactlibrary.FileProviderClass` to be totally separate things. And this is why I'll be blogging next week about how library developers need to be doing this sort of thing themselves, so people like you aren't stuck trying to work this out. – CommonsWare Jun 23 '17 at 21:02
  • @iremlopsum: Just to be clear... you are getting the exact same stack trace as originally? You're not crashing in a new place? – CommonsWare Jun 23 '17 at 21:03
  • I MADE IT WORK! Sorry for caps lock, It's just I have been working on this issue for far too long. So, now that you told me about getUriForFile(), I looked into it, and the really issue was that my android:authorities was wrong there, and all of this was really a dumb developer issue. But thank you so much for helping me out here! – iremlopsum Jun 23 '17 at 21:09