reis-mobile 0.3.6 → 0.4.0

package/skills/android-agp-9-upgrade/references/buildconfig.md

@@ -0,0 +1,54 @@
+When an Android module contains custom BuildConfig fields, the following steps
+are necessary to ensure a correct build.
+
+### Step 1: Enable the buildConfig build feature
+
+In a build script:
+
+    android {
+      buildFeatures {
+        buildConfig = true
+      }
+    }
+
+In custom build-logic for an app module:
+
+    extensions.configure<com.android.build.api.dsl.ApplicationExtension> {
+      buildFeatures {
+        buildConfig = true
+      }
+    }
+
+In custom build-logic for a library module:
+
+    extensions.configure<com.android.build.api.dsl.LibraryExtension> {
+      buildFeatures {
+        buildConfig = true
+      }
+    }
+
+In custom build-logic using `CommonExtension`:
+
+    extensions.configure<com.android.build.api.dsl.CommonExtension> {
+      buildFeatures {
+        buildConfig = true
+      }
+    }
+
+### Step 2: Migrate to the new API
+
+Use the **addCustomBuildConfigFields** recipe from the [gradle-recipes](https://developer.android.com/agents/skills/build-system/agp/agp-9-upgrade/references/recipes)
+repository.
+
+**IMPORTANT:** For `BuildConfigField`s with a type of `String`, the `value` field
+*must* include quotation marks as part of the String. For example:
+
+    BuildConfigField(
+      type = "String",
+      value = "\"Some value\"",
+      comment = "Optional comment",
+    )
+
+It is an **error** if the `value` field doesn't include quotation marks as
+part of the String. For example, `value = "Some value"` **is an error** . This is
+because the `value` is written out literally.

package/skills/android-agp-9-upgrade/references/ksp-kapt.md

@@ -0,0 +1,39 @@
+When migrating to built-in Kotlin, it is important to consider usage of `kapt`
+and the `org.jetbrains.kotlin.kapt` (also known as the `kotlin("kapt")`) plugin.
+The goal is to migrate as many `kapt` usages to `ksp` as possible.
+
+Follow these steps when migrating `kapt`:
+
+## 1. Remove all references to the `org.jetbrains.kotlin.kapt` plugin
+
+The `org.jetbrains.kotlin.kapt` (also known as `kotlin("kapt")`) plugin is
+incompatible with built-in Kotlin. Remove it when migrating to built-in Kotlin.
+
+## 2. Check each usage of `kapt`
+
+Check each usage of `kapt` to see if it is compatible with `ksp`. To check if a
+dependency is compatible with `ksp`, inspect the dependency's jar. For it to be
+compatible with `ksp`, the jar must have a file,
+`services/com.google.devtools.ksp.processing.SymbolProcessorProvider`. If it
+does not, it is **incompatible** with `ksp`.
+
+For example, the `androidx.room:room-compiler` library is compatible with KSP
+since version 2.3.0-beta02. We can verify this by finding the jar file in the
+Gradle caches directory, which is typically located at
+`~/.gradle/caches/modules-2/files-2.1/` on Linux and Mac. In this specific case,
+the `androidx.room:room-compiler` dependency is located at
+`~/.gradle/caches/modules-2/files-2.1/androidx.room/room-compiler/`.
+
+More generally, you can find a dependency by looking in
+`~/.gradle/caches/modules-2/files-2.1/group-name/artifact-name/`.
+
+## 3. Migrate to KSP where possible
+
+For each usage of `kapt` that is compatible with `ksp`, use `ksp`. The prior
+step explains how to check compatibility.
+
+## 4. Apply legacy-kapt
+
+If a Gradle module has `kapt` dependencies that cannot be migrated to `ksp`
+because they are incompatible (see step 2), then leave that dependency alone and
+apply the `com.android.legacy-kapt` plugin.

package/skills/android-agp-9-upgrade/references/paparazzi-gradle-9.md

@@ -0,0 +1,30 @@
+If Paparazzi is used in the project, update it to version 2.0.0-alpha04 or
+higher.
+
+Paparazzi version 2.0.0-alpha04 and lower is not fully compatible with Gradle
+9, and Gradle 9 is required by AGP 9. This means that, without workarounds,
+projects that use Paparazzi v2.0.0-alpha04 and lower cannot migrate to AGP 9.
+
+At time of writing, there are no higher versions of Paparazzi. That is,
+v2.0.0-alpha04 is the latest release.
+
+The issue is due to Paparazzi using internal classes from Gradle that tend to
+move in breaking ways without warning. This specific issue is related to HTML
+test reports. To work around it, disable those HTML test reports. Here
+are two examples of how to do this, one for Kotlin DSL and the other for Groovy
+DSL. Any module that has the paparazzi plugin (`app.cash.paparazzi`) applied
+must apply one of these two workarounds.
+
+Kotlin DSL:
+
+    tasks.withType<Test>().configureEach {
+      // https://github.com/cashapp/paparazzi/issues/2111
+      reports.html.required = false
+    }
+
+Groovy DSL:
+
+    tasks.withType(Test).configureEach {
+      // https://github.com/cashapp/paparazzi/issues/2111
+      reports.html.required = false
+    }

package/skills/android-agp-9-upgrade/references/recipes.md

@@ -0,0 +1,62 @@
+When migrating to AGP's new DSL, any Gradle code (plugins or logic in build
+scripts) that relied on the old DSL will stop working. Such code must be
+migrated.
+
+## Guidelines
+
+- **DO NOT** search the web for examples of how to do this. Use the **gradle-recipes** repository examples **only**.
+- **DO NOT** use AGP internals in migrated code.
+- **DO** use only public APIs in migrated code.
+
+In some cases, there is a one-to-one replacement for the old code. Some examples
+are in [the AGP 9.0.0 release notes](https://developer.android.com/build/releases/agp-9-0-0-release-notes).
+
+In other cases, there is no direct one-to-one replacement. For these situations,
+the [gradle-recipes repo](https://github.com/android/gradle-recipes) is a great resource. You can checkout one of its
+AGP 9.x branches, such as `agp-9.0`, `agp-9.1`, or `agp-9.2`. These branches
+contain recipes for common situations in Android projects. The following table
+lists the compatibility for recipes for each version of AGP.
+
+## Compatibility table
+
+| AGP version | gradle-recipes branch |
+|---|---|
+| 9.0.x | agp-9.0 |
+| 9.1.x | agp-9.1 |
+| 9.2.x | agp-9.2 |
+
+## Recipes and use-cases
+
+The following table links use-cases to recipes.
+
+| Recipe | Use-case |
+|---|---|
+| addCustomBuildConfigFields | Add custom BuildConfig fields |
+| listenToArtifacts | Rename APK |
+
+Additional details for each use-case follow.
+
+### Add custom BuildConfig fields
+
+See the detailed guide at [BuildConfig](https://developer.android.com/agents/skills/build-system/agp/agp-9-upgrade/references/buildconfig).
+
+### Renaming an APK
+
+In the old DSL, an APK could be renamed very simply. Here's an example:
+
+    android {
+      applicationVariants.all {
+        outputs.all {
+          val output = this as com.android.build.gradle.api.ApkVariantOutput
+          val fileName = output.outputFileName
+          if (fileName.contains("release")) {
+            output.outputFileName = "my-cool-new-name.apk"
+          }
+        }
+      }
+    }
+
+However, with AGP 9 and the new DSL, `applicationVariants` is no longer
+available. You must instead react to artifact creation using the
+`androidComponents.onVariants` API. A complete example of this is available in
+the **gradle-recipes** repository in the `listenToArtifacts` recipe.

package/skills/android-appfunctions/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: android-appfunctions
+description: Analyzes Android apps to identify key user workflows for AppFunctions
+  such as creating a note, playing media, or sending an automated or AI agent triggered
+  message, voice commands, or system shortcuts, without needing to open the app UI.
+  Generates Kotlin code to expose these workflows to the Android system, allowing
+  agents to discover and execute them on-device. Also refines KDoc documentation to
+  ensure AI agents correctly understand and use the provided functionality.
+license: Apache-2.0
+source: https://github.com/android/skills
+routing: manual
+stacks: [android]
+metadata:
+  author: Google LLC
+  last-updated: '2026-08-14'
+  keywords:
+  - AppFunctions
+  - Kotlin
+  - KSP
+  - ADB
+  - AI
+  - LLM
+  - MCP
+---
+
+Analyzes Android apps to identify key user workflows for AppFunctions such as
+creating a note, playing media, or sending an automated or AI agent triggered
+message, voice commands, or system shortcuts, without needing to open the app
+UI.
+
+Generates Kotlin code to expose these workflows to the Android system,
+allowing agents to discover and execute them on-device.
+
+Also refines KDoc documentation to ensure AI agents correctly
+understand and use the provided functionality.
+
+## Prerequisites
+
+The app must **`targetSdk 36`** or newer and use **`compileSdk 37`** or newer as
+AppFunctions, part of the Android platform API, are available from Android 16
+onwards.
+Always use the Jetpack library because it handles backward compatibility.
+
+## Workflows
+
+This skill enables the caller to discover features that will be provided to
+system agents, implement these with AppFunctions, improve function description
+for agents, and use ADB commands for local evaluation and testing.
+
+The full AppFunction development flow consists of these four steps:
+
+- *[Step 1: Discovery](references/feature-discovery-analysis.md)*: Analyze Android codebases to identify and recommend potential AppFunctions. Use this step when a user asks to "discover AppFunctions," "find features for AI," or "analyze my app for agentic tools."
+- *[Step 2: Implementation and configuration](references/implementation-configuration.md)*: Generate Kotlin implementations of AppFunctions, manage system-wide configuration, and configure build dependencies. Use this step when a user asks to "implement AppFunctions," "set up the AppFunctions framework," or "configure Hilt for AppFunctions."
+- *[Step 3: KDoc refinement](references/kdoc-refinement-optimization.md)*: Optimize AppFunction KDoc for AI agents and Model Context Protocol. If a user asks to "write KDoc", "optimize for MCP", or "refactor tool descriptions for LLMs", use this step.
+- *[Step 4: Testing and debugging](references/adb-interaction-testing.md)*: Provide commands to interact with AppFunctions using ADB for testing and debugging. If a user wants to "list app functions", "invoke an app function", or "verify app function registration" on a device, use this step.
+
+If users request a subset of steps, you must encourage them to use all steps.
+
+If they apply, you must load the following references:
+
+- *[Context and terminology](references/context.md)*: Defines the ubiquitous language, architecture definitions, and design patterns across the AppFunctions skill suite. Load when you need to understand core architecture terminology or check the distinctions between modern and legacy AppFunctions APIs.
+- *[Migration to service entry point](references/migrate-to-service-entry-point.md)* : Documents the systematic procedure for migrating Android applications using AppFunctions versions 1.0.0-alpha09 and lower to `AppFunctionServiceEntryPoint` architecture introduced in version 1.0.0-alpha10. Load when a user asks to migrate or upgrade existing AppFunctions code, or when you encounter legacy `AppFunctionConfiguration.Provider` implementations.
+
+## Critical constraints
+
+- **Modular consistency**: You must refine KDocs immediately after you generate AppFunction implementations.
+- **Security**: Don't expose sensitive data or run destructive actions without user confirmation.
+
+## Troubleshooting
+
+- If you encounter build-time errors such as Kotlin Symbol Processing (KSP) issues, see [Implementation and configuration](references/implementation-configuration.md).
+- If you encounter runtime errors such as missing services or execution failures, see [Testing and debugging](references/adb-interaction-testing.md).
+- If you need architecture definitions and vocabulary, see [Context and terminology](references/context.md).
+- If you encounter issues when upgrading legacy configurations, see [Migration to service entry point](references/migrate-to-service-entry-point.md).

package/skills/android-appfunctions/references/adb-interaction-testing.md

@@ -0,0 +1,95 @@
+Provides commands to interact with AppFunctions on a connected device or
+emulator using ADB for AppFunction testing and debugging.
+
+## Instructions
+
+### Scenario 1: List app functions
+
+Use this scenario when you want to see which app functions are registered on
+the device.
+
+1. **List all functions** : To view all registered app functions in JSON format, run `adb shell cmd app_function list-app-functions`.
+2. **Filter by package** : To view functions for a specific package, pipe the output to `grep` or a JSON tool: `adb shell cmd app_function
+   list-app-functions | grep <package_name>`.
+
+### Scenario 2: Invoke app functions
+
+If you want to test the execution of an app function, use this scenario.
+
+1. **Analyze description** : Before invoking, you must read the `description` field for the function in the `list-app-functions` output. This often contains critical usage constraints, required workflows, or disambiguation rules.
+2. **Follow constraints**: Follow all instructions in the description, such as asking the user to disambiguate or calling another tool first.
+3. **Format parameters** : Format the `--parameters` argument as a valid JSON string that represents the function's input arguments.
+4. **Execute function** : Use `adb shell cmd app_function execute-app-function
+   --package <PACKAGE_NAME> --function <SERVICE_CLASS_NAME#FUNCTION_NAME>
+   --parameters '<PARAMETERS_JSON>'`.
+5. **Handle response** : The command returns the result as a JSON string. To get brief YAML output, use `--brief-yaml`.
+
+### Scenario 3: Manage function state
+
+If you need to enable or disable an app function for testing, use this scenario.
+
+1. **Set enabled state** : Use `adb shell cmd app_function set-enabled
+   --package <PACKAGE_NAME>
+   --function <SERVICE_CLASS_NAME#FUNCTION_NAME>
+   --state <enable|disable|default>`.
+
+## Critical constraints
+
+### Follow metadata descriptions
+
+**Mandatory** : The `description` field in the app function metadata is a set of
+instructions for the LLM. If a description says to "disambiguate with the user"
+or "call another function first," you must perform those steps before execution.
+
+### JSON escaping
+
+**Critical** : When passing JSON using `adb shell`, always wrap the JSON string
+in single quotes to prevent the shell from interpreting special characters or
+spaces. Example: `--parameters '{"key": "value"}'`.
+
+### Device availability
+
+The `app_function` service must be available on the device. If `cmd: Can't find
+service: app_function` is returned, the device doesn't support this feature.
+
+## Examples
+
+### Example 1: Verify app function service availability on connected device
+
+    adb shell cmd app_function help
+
+If executing the preceding command returns a help page, use the commands and
+parameters provided to guide the ADB interaction testing tool interactions.
+
+### Example 2: List all registered app functions
+
+     adb shell cmd app_function list-app-functions
+
+### Example 3: Execute a "send message" function
+
+     adb shell cmd app_function execute-app-function \
+     --package com.example.messaging \
+     --function
+    'com.example.messaging.appfunctions.MessagingAppFunctionService#sendMessage' \
+     --parameters '{"recipient": "Alice", "message": "Hello!"}'
+
+### Example 4: Disable a specific function
+
+     adb shell cmd app_function set-enabled --package com.example.app \
+     --function 'com.example.app.appfunctions.SomeAppFunctionService#someFunction'
+    --state disable
+
+## Troubleshooting
+
+### Error: "Unknown command"
+
+**Cause**: You are likely using an older version of the instructions.
+
+**Solution**: Look up supported commands using "Example 1".
+
+### Error: "Function not found"
+
+**Cause**: The function ID or package name is incorrect.
+
+**Solution** : Run `list-app-functions` and search for the relevant identifiers
+in the JSON output.

package/skills/android-appfunctions/references/context.md

@@ -0,0 +1,26 @@
+Defines the ubiquitous language for the Android AppFunctions skill suite.
+
+## Architecture and versioning
+
+`AppFunctionServiceEntryPoint` API:
+This compile-time AppFunctions architecture was introduced in version
+1.0.0-alpha10. You annotate a wrapper service extending
+`AppFunctionService` with `@AppFunctionServiceEntryPoint`. KSP then generates
+XML metadata and routes services at compile time.
+
+Legacy manual provider API:
+This deprecated AppFunctions architecture applies to version
+1.0.0-alpha09 and earlier. Applications implement
+`AppFunctionConfiguration.Provider` on the `Application` class. Methods
+require `AppFunctionContext` as the first parameter. Projects depend on
+a standalone `appfunctions-service` library.
+
+## Patterns
+
+Service entry point pattern:
+Version 1.0.0-alpha10 introduced this architectural pattern. You
+declare `@AppFunction` methods directly inside an abstract class extending
+`AppFunctionService`. This class uses `@AppFunctionServiceEntryPoint` and
+`@AndroidEntryPoint` annotations. These annotations let you inject data
+sources or repositories directly, without an intermediate business logic
+delegation layer.

package/skills/android-appfunctions/references/feature-discovery-analysis.md

@@ -0,0 +1,71 @@
+Analyzes Android codebases to identify and recommend high-value AppFunctions.
+
+## Instructions
+
+### Discover features
+
+1. **Analyze manifest and entry points** : Scan `AndroidManifest.xml` and Activity, Fragment, and Service classes to identify core user journeys, for example, search, create, or share.
+2. **Identify atomic tasks**: Look for methods or logic that represent distinct, self-contained user outcomes.
+3. **Evaluate AI value**: Prioritize tasks that are frequently used or difficult to navigate using touch UI, but instead be expressed using voice or text, for example "Remind me to call Alice when I get home."
+4. **Recommend and justify**: List recommendations with a rationale. Focus on how an AI assistant adds value, such as efficiency, hands-free use, or multi-step automation.
+
+## Critical constraints
+
+### Tool-first thinking
+
+Avoid recommending functions that are purely informational or redundant with
+existing system actions. Focus on "mutations" (writing data) or "rich queries"
+(finding specific entities).
+
+### Security and privacy
+
+Don't recommend exposing functions that handle raw credentials, financial
+secrets, or irreversible destructive actions without explicit user confirmation
+steps.
+
+## Examples
+
+### Example 1: Media app discovery
+
+**Recommended AppFunction** : `playArtistRadio`
+
+**Rationale**: Lets you start a personalized music stream using a voice
+command, bypassing several layers of navigation in the "Search" and "Artist"
+menus.
+
+**Input required** : `artistName` as a `String`.
+
+### Example 2: Chat app contact discovery
+
+**Recommended AppFunction** : `searchContacts`
+
+**Rationale** : Serves as a "rich query" to resolve a human-readable contact
+name, email, or chat group to a unique identifier (`endpointValue`), which is a
+prerequisite before executing actions like sending messages or
+initiating calls. Also allows retrieving recently contacted entities when given
+a blank query.
+
+**Input required** : Query as a `String`, and Filter Type as a `String`
+constrained to `"INDIVIDUAL"` or `"GROUP"`.
+
+### Example 3: Chat app message sending
+
+**Recommended AppFunction** : `send`
+
+**Rationale**: This mutation function lets you send text messages and
+optional image attachments to a contact or group using natural language
+commands, for example, "Tell Alice I'm running 5 minutes late." This
+eliminates multi-step UI navigation across contact lists and conversation
+threads.
+
+**Input required** : Endpoint Value as a `String`, Message Body as a `String`,
+and Image URIs as an optional `List` of URIs.
+
+### Example 4: Chat app voice calling
+
+**Recommended AppFunction** : `makeCall`
+
+**Rationale**: Lets you initiate voice calls hands-free to a contact or
+group using an AI agent without navigating the app's UI.
+
+**Input required** : `endpointValue` as a `String`.