[Feature Request] Intent Launcher: support Broadcast intents

[ilonachan]

The Intent Launcher (& Shortcut) feature is extremely useful, but recently I've been limited by the fact that it only supports using startActivity to fire an Intent: the app ShizuTools has a feature where ADB commands can be triggered using intents; however this mechanism only accepts broadcast intents, since they don't start an activity but rather trigger a BroadcastReceiver.

So in the Intent Launcher, there should be a (dropdown?) option to change the execution mode from "Activity" to "Broadcast". I've already implemented a rudimentary version of this and can confirm it works well. I've also seen that, for example in the list of selectable intent actions, a bunch of potential options are commented out with the note that they are broadcast intents (and therefore currently unsupported); these could be contextually enabled depending on the execution mode.

Obviously this new option should also be persisted in the history database; I've already tested that a simple migration works well to do this upgrade seamlessly.

What has turned out more complicated is the creation of shortcuts for these broadcast intents, since shortcuts seem to actually only support the startActivity mode. A workaround for this is to run startActivity with a special springboard activity inside ActivityManager, have that activity retrieve the necessary information either from the intent extras (which I've tried and failed to make work) or from the (history?) database. I've tried this and it works well, but there are kinks to work out (eg task affinity) and potential security concerns, tho mostly in the case where an arbitrary intent is passed inside the intent (PendingIntents cannot be used since they cannot be broadcast, unless I just missed that API).

In the case where the history database is used as ground truth instead, it would be ideal to ensure that the history entry cannot be deleted while a shortcut for it exists, or the user should at least be warned and the shortcuts deleted. I haven't explored how much of this is possible with the Shortcut APIs.

As may have been clear from my wording already, I've already tinkered with this and am more than willing to provide a PR. I can't vouch for its quality or style conformity, but I'm trying my best.

[ilonachan]

Maybe this comment rather belongs in a yet-to-be-made PR, but my current implementation deviates from the initial proposal as follows:

• the springboard activity already existed, oops. I've extended it without losing any functionality.
• shortcuts don't share the history database, which just makes sense. They currently get their own one, because while having more than one database seems to be bad practice with Room, it's already being done so meh.
• an app can't remove pinned shortcuts, but it can delete them and show the user an error message... that seems like the wrong way round in hindsight. It is however possible for an app to list all pinned shortcuts currently out, and ActivityManager could run a periodic background job to delete the backing data for all IDs that are no longer on the launcher. Super low priority, could just be run every 24hrs if that.