KIOSK APP GENERATOR configurations

The following configurations are available for KIOSK APP GENERATOR:

theme_color accepts #rrggbb or #rgb. If a wallpaper is visible, the wallpaper is the visual background; if no wallpaper is present, the theme colour becomes the launcher background and KAG adapts text and system-bar icon contrast automatically.

banner_text is capped at 80 characters. It is intentionally short: it is for a site label, device role, deployment note, or simple instruction, not a full help document.

orientation accepts auto, portrait or landscape. icon_size accepts small, medium, large or xl. The XL preset is 128dp and is most useful for sparse layouts where the standard sizes look undersized; dense grids still shrink icons to fit.

icon_grow_to_cell only applies when icon_size is xl. When enabled, XL becomes a floor rather than a ceiling and icons can expand into available cell space up to 512dp. This is useful for very sparse grids on large landscape displays, but should be used deliberately: Android app icons are commonly authored around 192-432dp, so growing much beyond that can visibly soften bitmap-backed icons. The folder overlay deliberately does not apply this toggle.

The browser form and scripted API submissions that omit rows and cols both start at 4x5. The grid is capped at 20x20 (400 cells total) by the validator. Apps and folders share the same grid, and two tiles cannot occupy the same row and column. The launcher does not create an overflow page or scrollable area; cells are sized to fit the available viewport, and dense grids reduce tile/icon size accordingly.

The app list is submitted as part of the config_json payload (see Configuration import / export below). Each app entry has the following shape:

Apps must already be installed on the target device for the launcher to launch them. KAG does not bundle the referenced apps, and Android's kiosk policy must allow the target packages to launch in lock task.

The package name validator expects a normal Android package identifier: at least one dot, no leading or trailing dot, ASCII letters, numbers, underscores and dots only, and no more than 255 characters.

Tiles can be grouped into folders, each occupying a single grid position. Same JSON shape:

Folders have a 2-app minimum and a 9-app maximum. The closed folder tile shows a small preview of contained apps; tapping opens the folder as an overlay. background_color applies to that open overlay, not the closed preview tile, so the main launcher grid stays visually consistent.

Folder apps do not have their own row and column; they render in submission order. Duplicate packages are blocked inside a single folder, but the same package can appear elsewhere if you deliberately want it exposed in more than one place.

A wallpaper source can be a bundled image (uploaded with the build, served from the APK's assets) or a remote URL (fetched at runtime).

If an uploaded wallpaper is supplied, it is bundled into the APK. If a remote URL is supplied, the launcher fetches it on-device and caches it. If neither is supplied and no theme colour was explicitly selected, KAG draws the default procedural gradient wallpaper from a vector drawable. If neither is supplied and a theme colour was selected, KAG uses the colour-only background.

Controls what level of Android Settings exposure end users have from the launcher. Two routes: KAG's own granular per-intent toggles, or delegate to MANAGED SETTINGS for the same job done by a dedicated utility.

Settings panels are still Android Settings activities. If an OEM allows sideways navigation from the target screen to other areas of Settings, KAG cannot prevent that alone. Keep Settings access blocked in policy, and test the exact OEM build before deploying to production.

The generated launcher includes a managed configuration schema. This means an EMM can override many runtime values after installation, without rebuilding the APK.

For day-to-day administration, the most useful managed configuration keys are the ones that change the launcher without rebuilding the APK:

The advanced managed configuration keys are for replacing whole parts of the launcher:

Typed managed-configuration overrides sit on top of kiosk_config_json. A common pattern is to build a clean baseline in the generator, export kiosk_config.json, paste it into the EMM as kiosk_config_json, then use typed fields for site-specific changes such as wallpaper, banner text or rows and columns.

The settings bundle is treated as an override only when it contains at least one enabled value, including use_managed_settings. This avoids EMM consoles that auto-save every default value accidentally wiping the generated settings. If the goal is to turn every settings option off, use kiosk_config_json and set "settings": { "enabled": false } there.

When authoring folder data manually, use the delivered bundle-array shape rather than the manifest wrapper shape. Each folder object carries its fields at the top level:

{
  "folders": [
    {
      "folder_name": "Tools",
      "folder_row": 1,
      "folder_col": 0,
      "folder_apps": [
        { "folder_app_package": "com.android.settings" },
        { "folder_app_package": "com.google.android.deskclock" }
      ]
    }
  ]
}

sign_mode accepts bayton (signed with Bayton's certificate, unique package name per build unless an update code is supplied), release (signed with the uploaded keystore), or debug (auto-signed with an Android debug key; sideload testing only).

output_format accepts apk (direct install via EMM push or sideload) or aab (required for upload to Managed Google Play).

Every build ships an exported kiosk_config.json file alongside the APK. This is the complete payload that produced the build, including the update code, useful for auditing the deployment or re-importing into a future build (paste it into the form's Import config field to pre-populate every setting).

The schema is documented inline above (each form-field table is the same schema you'll see in the exported file). The file is also available via /api/kiosk-config/{id} while the build artefacts are still live.

Because the export contains the update code, treat it as sensitive. Anyone with that file can rebuild against the same package name while the package registry entry exists.

Every successful build also exposes a source archive containing the post-substitution Android project. This is useful when you need to audit what was compiled, keep evidence for change control, or rebuild independently.

The archive includes the generated Kotlin, XML, Gradle files and a small build metadata file. It does not include uploaded keystores or signing passwords. Debug builds work out of the box; release builds require signing.properties to be filled in from the included template.

KAG is primarily designed as a browser tool. API access is available, but not public; it can be enabled commercially for customers who need to integrate launcher builds into CI/CD or other internal automation flows.

These are the service surfaces integration work would build around:

Download links are intentionally short-lived. Build artefacts expire after first access and are purged after the retention window, so keep the exported config and update code with your deployment records.