[Feature]: Finalize one-shot provisioning bundle and publish the next GitHub Release

[awatchar]

Problem to solve

Minimum should provide an operator-friendly one-shot provisioning package, similar to the provisioning workflow previously completed and verified for the T56.

The package should allow an operator to prepare a supported radio from a Windows workstation without requiring a complete source checkout, Android Studio, Gradle, or manual execution of multiple PowerShell scripts.

The completed application and provisioning tools should also be published together as versioned assets on the GitHub Releases page.

Existing implementation

The repository already contains the main components of this workflow:

• Provision Minimum Device.cmd
• scripts/provision-minimum-device.ps1
• scripts/prepare-t56.ps1
• scripts/prepare-t99.ps1
• scripts/prepare-ryks.ps1
• docs/PROVISIONING_BUNDLE_README.txt
• .github/workflows/release-apk.yml

An earlier prerelease, 3.7.3-minimum.1, already published a signed APK and provisioning ZIP.

This Issue is therefore intended to:

1. Review and finalize the one-shot provisioning workflow.
2. Include all completed and approved changes since the previous release.
3. Verify the provisioning bundle on the supported hardware.
4. Publish a new GitHub Release containing both the APK and the standalone provisioning package.

Desired outcome

An operator should be able to:

1. Download one provisioning ZIP from GitHub Releases.
2. Extract the ZIP on Windows.
3. Connect one authorized radio through ADB.
4. Double-click Provision Minimum Device.cmd.
5. Allow the script to identify and verify the supported hardware model.
6. Install the included Minimum APK without clearing existing app data.
7. Apply the appropriate guarded model-specific provisioning procedure.
8. Register or verify the displayed Minimum Device ID.
9. Wait for Minimum to reach the Ready state.
10. Reboot the radio.
11. Confirm that Minimum automatically returns to Ready.
12. Receive a clear PASS or actionable failure message.

The operator should not need a source checkout, Gradle, Android Studio, or manual knowledge of the individual provisioning scripts.

Supported device profiles

The one-shot launcher should support only explicitly approved hardware profiles:

• T56: UNIPRO / ZX
• T99: Youdotech / QM011
• RYKS: ELINK / ym_258

Unknown or ambiguous hardware must be reported and rejected before APK installation or any provisioning change is performed.

Model-specific behavior must remain isolated. Hardware mappings, PTT rules, Location policy, and other settings must not be copied between device models without physical acceptance evidence.

Provisioning requirements

The one-shot provisioning workflow should:

• Detect an authorized ADB device safely.
• Support the standard ADB port 5037 and the existing Minimum lab port 5041.
• Require explicit selection when more than one valid target is connected.
• Verify the manufacturer and model before making changes.
• Reject unknown, unsupported, unauthorized, or ambiguous targets.
• Install the APK without clearing Minimum app data.
• Preserve the existing Minimum Device ID and configuration when upgrading.
• Stop with a clear explanation when an installed debug-signed APK cannot be upgraded by the release-signed APK.
• Run the correct guarded model-specific preparation script.
• Configure or verify required Android permissions.
• Configure or verify managed Location according to the device profile.
• Configure or verify the approved Wi-Fi profile when requested.
• Remove Zello for Android user 0 only through the approved and recoverable procedure.
• Launch Minimum and obtain the six-character Device ID.
• Open the Minimum Portal for device registration when required.
• Wait until managed configuration is active and the radio reaches Ready.
• Reboot the device and verify unattended startup.
• Confirm that the same Device ID remains active after reboot.
• Finish with an explicit PASS only after post-reboot Ready verification succeeds.
• Provide actionable error messages when any step fails.
• Avoid displaying or logging passwords, access tokens, bearer tokens, signing credentials, or private configuration data.

Standalone provisioning bundle

The GitHub Release should include a ZIP archive named using the release tag, for example:

minimum-provisioning-<version>.zip

The extracted bundle should contain at least:

minimum-provisioning-<version>/
├── Provision Minimum Device.cmd
├── minimum-foss.apk
├── README.txt
├── VERSION.txt
├── scripts/
│   ├── provision-minimum-device.ps1
│   ├── prepare-t56.ps1
│   ├── prepare-t99.ps1
│   └── prepare-ryks.ps1
└── assets/
    └── t99-wifi-provisioner.apk

The bundle must be self-contained for normal provisioning use and must not depend on files outside the extracted directory, except for documented workstation requirements such as Android Platform Tools.

GitHub Release requirements

Publish a new versioned GitHub Release from an exact reviewed tag.

The Release should contain:

• minimum-<version>-foss.apk
• minimum-<version>-foss.apk.sha256
• minimum-provisioning-<version>.zip
• minimum-provisioning-<version>.zip.sha256

The Release workflow should:

• Build from the exact Git tag.
• Build and run the required automated tests.
• Assemble the FOSS release APK.
• Sign the APK using the protected GitHub release environment.
• Verify the APK signature.
• Verify the expected application ID.
• Verify versionCode.
• Verify that versionName matches the Git tag.
• Build the temporary Wi-Fi provisioning helper.
• Package the standalone Windows provisioning bundle.
• Verify that all required bundle files are present.
• Generate SHA-256 checksums.
• Reject bundles containing secrets, signing files, credential stores, or private configuration.
• Publish all approved artifacts to the same GitHub Release.
• Generate release notes describing completed changes and known limitations.

Documentation requirements

Update the provisioning documentation so that an operator can complete the workflow without reading the source code.

The documentation should clearly explain:

• Windows and ADB requirements.
• How to extract and start the provisioning bundle.
• How the device is selected and verified.
• Which device models are supported.
• How Device ID registration works.
• Any operator interaction required by Android.
• The meaning of PASS and common failure messages.
• How to verify the SHA-256 checksums.
• The APK signature-mismatch limitation when upgrading from a debug build.
• How to recover safely after an interrupted or failed provisioning attempt.
• Which actions are intentionally not automated for safety reasons.

Verification

Before publishing the Release:

• Run the relevant Android unit tests.
• Build the signed FOSS release APK successfully.
• Verify the APK package, version, and signature.
• Test extraction and execution of the standalone ZIP on a clean Windows workstation.
• Confirm that the provisioning workflow does not require a source checkout or Gradle.
• Confirm that no credentials or signing material are included.
• Perform at least one real-device provisioning test for each device profile claimed as supported.
• Verify Ready before and after reboot.
• Record any unverified hardware behavior as a known limitation rather than treating it as passed.

Acceptance criteria

• Provision Minimum Device.cmd starts the guided one-shot workflow by double-clicking.
• The workflow requires no command-line parameters for the recommended setup.
• The operator does not need the source repository, Gradle, or Android Studio.
• The correct supported device profile is detected and verified.
• Unknown or ambiguous hardware is rejected before changes are made.
• The bundled APK is installed without automatically clearing existing app data.
• Existing Device ID and configuration are preserved during a compatible upgrade.
• The script stops safely and explains any APK signature mismatch.
• Model-specific provisioning remains guarded and isolated.
• Minimum reaches Ready before reboot.
• Minimum reaches Ready again after reboot.
• The Device ID remains unchanged after reboot.
• The script reports PASS only after all required checks succeed.
• A new reviewed Git tag is created for the release.
• The GitHub Release contains the signed APK.
• The GitHub Release contains the standalone provisioning ZIP.
• SHA-256 files are published for both the APK and ZIP.
• APK identity, version, and signature are verified automatically.
• The provisioning ZIP contains all required scripts and assets.
• The provisioning ZIP contains no credentials, tokens, private configuration, keystores, or signing material.
• Release notes describe the completed changes, supported models, and known limitations.
• Real-device verification results are recorded before the release is promoted as stable.

Safety and security considerations

• Do not include server passwords, access tokens, bearer tokens, Wi-Fi passwords, APRS passcodes, private keys, certificate fingerprints, or signing material in the repository or Release.
• Do not print sensitive values in the console or pass them through visible ADB command arguments.
• Do not clear Minimum app data automatically.
• Do not rewrite Android or USB serial numbers.
• Do not modify Android keylayout files as part of general provisioning.
• Do not apply T56, T99, or RYKS hardware mappings to another model without physical verification.
• Do not publish the Release as stable until the claimed hardware acceptance tests have passed.