Create plugin architecture

[kylecorry31]

trafficstars

Research how a plugin can be added.

• [ ] Create an example plugin that has a UI and provides some data to Trail Sense (two way)
• [ ] Create a way to show the UI of a plugin (might just mean that Trail Sense can enable or disable a built in tool if the plugin is installed)
• [ ] Create a way to communicate with a plugin (if services/broadcast receivers are used, create a implementation)

Questions

• [ ] How can Trail Sense communicate with the plugin?
• [ ] Can the plugin add UI to Trail Sense or does the UI need to be implemented in Trail Sense and call out to the plugin's service?
• [ ] How can Trail Sense detect if the plugin is installed? (I previously experimented with app queries for this, back when offline maps was a "plugin" - though that acted as a launcher for a standalone app)
• [ ] How do permissions work for plugins?

[kylecorry31]

https://developer.android.com/guide/components/aidl

[kylecorry31]

https://stackoverflow.com/questions/70674239/android-12-breaks-aidl-ipc-with-runtime-permissions-on-ipc-apk

[kylecorry31]

[kylecorry31]

[kylecorry31]

Services

Plugins can declare services that extend the capabilities of Trail Sense. There are two types of services used by Trail Sense - resource services and tool services.

Resource services

Resource services are essentially APIs that Trail Sense can retrieve data from. An example is a weather provider. Services must be able to respond to messages (using the Messenger API on Android) containing "route" (String) and "payload" (ByteArray - optional) and they must reply to the calling Messenger with data containing "route" (String), "payload" (ByteArray - optional), and "code" (Integer - 200 is success).

Resource services must define the following routes:

• /registration
  • Must return a 200 code with a JSON payload (ByteArray) matching the below definition

  {
    "name": "The name of your plugin",
    "version": "The user readable version of your plugin",
    "features": {
       // This is not well defined yet, but it will be an object of feature types (ex. "weather", "mapLayer") to a list containing objects that tell Trail Sense how to call it
     }
  }
  

Unofficial plugins (those that aren't signed with an official Trail Sense signing key) will need to pass a permission check as well before some features are invoked. For example, when obtaining weather for a location the plugin must have permission to view the user's location before Trail Sense will send it location data. Trail Sense does not care what additional permissions the plugin has, but will list them out to the user before it sends data over to it. I may enforce this on official plugins as well - TBD.

Some official plugins may have additional routes exposed that are not picked up by the registration. These can't be swapped out for a community plugin.

If there are multiple plugins that offer the same feature, Trail Sense will prefer the official one and offer a way for the user to change which is used. If there is no official plugin, but there are multiple community plugins, then Trail Sense will choose the one with the alphabetically lowest package ID.

Tool services

Not yet defined - but likely just Trail Sense starting/stopping a service via an intent. Not community swappable.

[kylecorry31]

See #3161