os_intents_android 0.3.1

Android implementation of os_intents: bridges generated AppFunctions and shortcuts into Dart. You want os_intents — this resolves with it.

example/README.md

What this package is for

You do not depend on this directly. Add os_intents and this resolves with it.

It carries the Kotlin runtime behind both Android layers, which fail in different ways and are worth telling apart.

App shortcuts — generated by default

os_intents sync writes res/xml/os_intents_shortcuts.xml, and os_intents install points the launcher activity at it. This package routes the launch:

launcher tap → MainActivity's Intent → this plugin reads osintents://intent/<id>
             → your handler, on the UI isolate

A shortcut always opens the app. A shortcuts.xml <intent> starts an Activity, so on this layer Execution.background does not mean headless — the handler runs in the app the user is now looking at. That is not a limitation of this package; there is nowhere else for it to run.

An intent with a required parameter gets no launcher shortcut at all: a tap carries no values and there is nobody to ask, so it would appear and then fail on use.

AppFunctions — opt-in, and the headless one

Behind os_intents sync --android, because it forces compileSdk 37, AGP 9.1.1 and Gradle 9.3.1 on your app for something only Android 16+ can run.

Here there is no Activity by definition — an AppFunctionService never has one — so every invocation goes through a second FlutterEngine started inside the app process. Execution.static_ short-circuits even that: the generated function reads SharedPreferences and answers without bringing an isolate up.

Checking it arrived

Three separate questions, all of which fail quietly:

$ dart run os_intents_cli:os_intents doctor --android   # is it in the APK?
$ dart run os_intents_cli:os_intents doctor --device    # did the system accept it?

The device one matters most for shortcuts: ShortcutManager drops what it will not take without reporting it, and resolves every label through the resource table. A label coming back as os_intents_addTask_label_short means the string resource never made it into the build.

Not implemented, and why

Entities. androidx.appfunctions 1.0.0-alpha10 has no entity concept — its AppSearch index holds the app's functions, not its data. @AppEnum does work, because a closed set needs no query.