Design flaw

[krischik]

I have two apps into which which a added aFileChooser (patched version with extension filter and base path).

When I started the demo for testing I saw:

Now I have three identical choose files options.

That makes me wonder if there is not fundamental design flaw inside aFileChooser. I beginn to think that one library can not be an external and internal file chooser at the same time.

[iPaulPro]

So, when 4.4 introduced the Storage Access Framework and this DocumentProvider Activity, they made it so the Activity intercepting the GET_CONTENT Intent must be exported. If you're going to export FileChooserActivity you should be using your own icon so the user is able to tell that it's your app they can select a file from. I will update the README to include this direction.

FileChooserActivity can be used independently from GET_CONTENT method, which has it's own utility. For this type of usage, the icon doesn't matter, and exported should be false.

Also, as noted in the README:

Using FileChooserActivity and LocalStorageProvider together are redundant if you're only trying to insure your user has access to local storage. If this is the case, you should enable/disable based on the API level (above: @bool/use_provider and @bool/use_activity).

[iPaulPro]

Remember, if you're only trying to determine if the user has an app that supports the GET_CONTENT Intent that you want, you can always check for it at runtime with something like this:

public static boolean isChooserAvailable(Context context, Intent intent) {
    final PackageManager mgr = context.getPackageManager();
    List<ResolveInfo> activities = mgr.queryIntentActivities(intent, 0);
    return activities.size() > 0;
}

I will add this to FileUtils at some point, and update the README.