Fix potential null pointer error issue.

[agamemnus]

See: apache/cordova-android#126.

I am writing a Google Play APK expansion library.

All the libraries I have seen so far store version data inside the content provider's tag as meta-data, and again inside a separate .xml file. This is wrong, but they are forced to do this because it is very difficult to figure out the code to source all data from one xml file. I have done this, but it does require telling Cordova not to extract the zip file before the plugin file is ready.

To do that, I return a null value from APEZProvider (extends ContentProvider for APKs) if the APK expansion plugin class instance didn't run yet. That of course causes Cordova to crash because it doesn't have the null test I am proposing.

[sqliu]

lgtm. @agamemnus could please also refine the commit log as apache/cordova-android#126 thanks!

[rakuco]

Since that's been sent upstream (thank you so much for doing that), it would be better to cherry-pick it from there once it's merged.

[agamemnus]

sqliu, "refine the commit log"? I don't understand what that means, sorry. :-(

[baleboy]

I think he is asking to repeat what the commit does as described in the cordova commit (as opposed to just putting a link)

[agamemnus]

All right. I got a response there, and seems that throw new FileNotFoundException (); will work instead of modifying CordovaResourceApi.java, but I wonder if it is the most correct thing to do, since it is not really that the file isn't found, but that openAssetFile won't even try open the file (as intended, due to my changes).

So in other words:

 @Override public AssetFileDescriptor openAssetFile (Uri uri, String mode) throws FileNotFoundException {
  if (initIfNecessary () == false) throw new FileNotFoundException (); // or return null?
  String path = uri.getEncodedPath ();
  if (path.startsWith("/")) path = path.substring (1);
  return mAPKExtensionFile.getAssetFileDescriptor (path);  
 }

Can you give some input on this?

[rakuco]

I'd discuss this in the upstream PR and tend to follow whatever suggestions are made there, since the people reviewing the code are normally the maintainers and the people who wrote it.