Currently plugin searching still works in two stages, first it searches
for all plugin broadcast receivers and then waits for all the answers
to complete the plugin map. If any of plugins doesn't answer the call
this means all of them won't be shown and that's not very user-friendly.
The change simplifies plugin search to just package scan for specific
broadcast receivers. Android provides package name and app info for it.
We don't need any other info from plugins, so we don't need to wait for
broadcast roadtrip.
Further improvements:
* introduce meta-data and uses-feature tags in
plugin manifests and get rid of broadcast receiver completely.
* Implement view in settings activity with list of installed plugins
When you have a music folder /music and a playlists folder /music/playlists , then reading a playlist with a song ../a.mp3 inside resolved to "/music/playlists/../a.mp3" , which broke the import operation. Using getCanonicalPath instead of getAbsolutePath fixes the issue, since the former resolves the URI to /music/a.mp3
* Add playlist path relativization option.
Allows relative paths to be specified/exported within synchronized playlists.
* Minor code clean up for relative playlist exports.
Removes some unnecessary code and slightly improves associated Javadocs.
* add helper for shared preference to organize code more
* requested changes to pull request #901
-add the usual copyright / license boilerplate to SharedPrefHelper.
-edit the comment on method getSettings in SharedPrefHelper
* requested changes to pull request #901
-add the usual copyright / license boilerplate to SharedPrefHelper.
-edit the comment on method getSettings in SharedPrefHelper
We are now fully switched to activity-based plugin
start system, so we don't need to start service or
wake activity anymore. Delete relevant part.
If the additiona; information is needed about the
plugin we can dig it out from its broadcast receiver.
Also, add quick "Plugins" button to the full playback
activity so there are only 2 clicks away from any plugin.
