Support Android Nougat (7.0) architecture

[Eric Snell]

This encompasses the following and possibly more issues: Datasource branch #29 identify by mime type #149 some NIO classes not available #163 Uri instead of file path #173 InputStream instead of file

tl;dr - In the near future on Android I don't have a file path and I don't have a file extension. All I have is an InputStream, OutputStream, and MIME type. The source/sink is unknown and the Uri I'm given may not contain the concept of an extension. I need an interface into jaudiotagger that supports these concepts: read here (InputStream) write here (OutputStream) and MIME type (this is what you're reading/writing)

Here's bit more detail:

Android is moving away from a file scheme and to their ContentResolver and ContentProvider architecture. Very briefly, a ContentResolver is a global singleton that, given a "content://" Uri, finds a ContentProvider responsible for the underly data (Database, file system, etc). Think of ContentResolver providing CRUD operations using the ContentProvider responsible for that content. In the jaudiotagger context, the ContestResolver operations we would be interested in are getType(Uri), openInputStream(Uri), and openOutputStream(Uri).

As a developer that wants to use jaudiotagger, why do I care? Because I'm losing permissions (since KitKat) to just go anywhere and open any file. Instead, I have to use this new architecture. One big reason for the switch is security, but no need to debate. It's the direction. If my app owns the files, there is no issue. Also, even if I'm dealing with a file, the ContentProvider need not reveal that to me via the Uri. content://authority/path/id is the Uri structure and the provider need be the only one to understand it fully.

File uri are going away on Android and it's already started. Starting in Nougat you can't even pass a file:// uri to another app to use. https://commonsware.com/blog/2016/03/14/psa-file-scheme-ban-n-developer-preview.html

This issue is not new, it's just that they are migrating a bit at a time. I already use this framework in my app to allow a user to choose a playlist to import. I send an Intent.ACTION_OPEN_DOCUMENT to allow my use to select the file and I'm returned one of these content:// uri. Right now it has a file extention, but I can't get to the file. I have to use the InputStream. In the future, you can't count on the extention being there.

So that general architecture in the datasource branch, which I haven't really looked at, would become more and more necessary. If you invert things a bit, the user could plug in a datasource and jaudiotagger doesn't care where the data resides. jaudiotagger only need provide the interface and the contract. And you'd provide a file data source by default.