os_intents_android 0.4.0

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

0.4.0

A needsConfirmation answer reaching an AppFunction is reported as a failed action carrying the handler's fallback line. There is no user in front of a headless function to show choices to, so "unperformed, and here is why" is the honest translation — an agent relays the fallback ("Open the app to …") instead of pretending the action ran.

0.3.2

The floor 0.3.1 claimed now actually builds

On Flutter 3.35 — the oldest Flutter this package resolves on — 0.3.1's Gradle script compiled the module without its Kotlin: the Kotlin plugin was never applied (newer Flutters apply built-in Kotlin themselves, older ones apply nothing), so the app failed at GeneratedPluginRegistrant with cannot find symbol: OsIntentsAndroidPlugin. The script now follows the built-in-Kotlin migration guide: on AGP 8 it applies the Kotlin plugin, on AGP 9+ it stays out of built-in Kotlin's way. Caught by the new CI job that builds a consumer app on the floor Flutters, and verified there.

The minSdk 24 requirement is now stated in the README rather than discovered from a manifest-merger error — it is Flutter's own template default since 3.35, so only apps created by an older Flutter have the one-line change to make.

0.3.1

Lower SDK floor

The runtime packages now accept Dart 3.8 / Flutter 3.32. Nothing in them needed the old ^3.12.2 floor — it only stopped the package from resolving in projects that are not on the newest stable. 3.8 rather than lower because that is where the dev toolchain still resolves (flutter_lints 6 wants 3.8) and where the current dart format style holds; the analyzer confirms the code at language 3.8, and the test suites pass.

0.3.0

The Kotlin half of the same change as os_intents_ios. IntentOutcome gained message and failureMessage, invoke throws OsIntentsException for a failed action however it was reported, and staticOutcome — what generated code now calls on the static path — does the same for a published IntentResult.failure.

0.2.0

Dynamic shortcuts

New DynamicShortcuts, wrapping ShortcutManager behind pushShortcut, shortcuts, removeShortcuts and maxShortcuts.

The Intent each entry carries is the same shape the shortcuts emitter builds — dev.osintents.action.RUN with osintents://intent/<id> — so a tap lands in the routing that already exists rather than in a second path that could drift from it. Values ride as extras, which is what that routing already reads.

Null below API 25, where ShortcutManager does not exist, which surfaces as "the platform did nothing" — the same answer iOS gives, so one Dart code path covers everything.

donate still returns false. That has not changed and is not a gap: this is the call it was pointing at.

0.1.0

First released version. Android implementation of os_intents — you depend on that package, and this one resolves with it.

Carries the runtime behind both Android layers: the headless FlutterEngine a generated @AppFunction invokes, the routing that turns an app-shortcut launch into a handler call on the UI isolate, and the SharedPreferences store an Execution.static_ function answers from without starting an isolate.