Repository navigation
Read launch-time test hooks only in development builds - #488
Merged
Merged
Conversation
ymote
force-pushed
the
fix/launch-input-test-hooks
branch
from
October 11, 2026 14:18
7e61173 to
9c90385
Compare
Home's main activity is exported, so any installed app can start it with intent extras, and Makepad copies `makepad.<NAME>` extras into the environment. OctoSense code read several of them in release builds. - shell: `launch_input` is the one reader of MAKEPAD_APP_CONFIG. Its test actions, Mail's demo mailbox and module open parameters apply only in a development build (cfg(dev_mode): debug or --features dev-mode); a release build ignores them and logs that once. Desktop --test-action command-line flags are unchanged. - kernel: the launch proxy (makepad.OCTOS_PROXY) applies only in a development build; new `dev-mode` feature, forwarded from the shell through ai-host. - AppCard: every MAKEPAD_* hook (provisioning, seeding, auto prompt, fake GPS, proxy, dumps) goes through `launch_var`, development builds only; new `dev-mode` feature, forwarded from the shell through the module. - OpenHarmony: EntryAbility forwards no launch parameters unless build-home-ohos.py --dev-mode stages it (a separate bundle id required). - Android: Home's `dev-mode` feature comes from build-home.py's `--dev-mode` (App Studio's, #477): standalone only, never the installed Home's identity under its signer, and ROM staging refuses it. So a build that reads launch input is never the installed Home. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Docs and scripts that passed `makepad.*` launch extras to release packages now name a development test build: `rom/scripts/build-home.py --dev-mode` under a separate package name on Android, `build-home-ohos.py --dev-mode` on OpenHarmony, `--features dev-mode` for the desktop mail demo, and `DEV_MODE=1` / `--features dev-mode` for AppCard's own tools. `provision-appcard-llm.sh` requires PACKAGE=dev.makepad.octosense.<suffix>. AGENTS.md states the rule; English and Chinese docs change together. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A desktop's environment is the local user's, like a command-line flag, so `MAKEPAD_APP_CONFIG` (test actions, Mail's demo mailbox, module-open settings) and AppCard's `MAKEPAD_*` hooks are read in every desktop build. The gate applies only on Android and OpenHarmony, where a launch Intent extra or launch parameter can come from another app: there a release build ignores them and only a development build reads them. - crates/shell/src/launch_input.rs: `honoured` keys on `cfg(native_mobile)`; tests say a phone release build ignores it while a desktop build (any profile) and a phone development build read it. - apps/appcard: `launch_set_in(mobile, development, ...)` — a desktop reads the hooks, a phone only in a development build. - Docs restored to plain desktop `cargo run` commands; the phone and OpenHarmony guidance keeps the development-build note. AGENTS.md states the desktop/phone split. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Protects a release Home now, without waiting for a makepad sweep: the shell's pinned makepad gains the Studio/OCTOS_PROXY launch-input gate from OctoSense-org/makepad#119 as the next stacked runtime patch over the pinned base, so a shipped Android Home ignores a Studio host or app proxy from an Intent extra. The OpenHarmony template part of #119 is not carried here, since Home builds its own OpenHarmony entry ability. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ymote
force-pushed
the
fix/launch-input-test-hooks
branch
from
October 11, 2026 18:16
9c90385 to
5b8e4ec
Compare
ymote
marked this pull request as ready for review
October 11, 2026 18:16
Contributor
Author
|
Merged in a train (#488 → #501 → #495) on two local runs of the train head 37008bb, which contains this PR's head 5b8e4ec. Merged in order with
Run 2's table
Notes:
Run 2's first attempt on the same head stopped at one failure outside this train: GitHub's native Windows acceptance ( |
This was referenced Oct 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
On a phone, Home's main activity is exported (the app drawer entry, the Home app, a share target and a deep-link target), so any installed app can start it with intent extras, and Makepad's Android glue copies
makepad.<NAME>extras into the environment. OpenHarmony passesmakepad.*launch parameters on the same way. OctoSense code read several of these in release builds: test actions, Mail's demo mailbox, module-open settings, the kernel's launch proxy and AppCard's provisioning and seeding hooks.This hardens them. On a phone (Android, OpenHarmony), launch-time test, demo and provisioning hooks are read only in a development build (
cfg(dev_mode): a debug build, or--features dev-mode; never a store build); a release build ignores them and logs once that it did, without the value. On a desktop they are read in every build, because a desktop's environment is the local user's own, the same trust as a command-line flag — this keepsMAKEPAD_APP_CONFIG='{"mail_demo":true}'and the other documented desktop flows working. Desktop--test-actionarguments are unchanged.A separate change closes the one channel Makepad itself acts on in a release build (the Studio connection and the
OCTOS_PROXYapp proxy), which a shell-side gate cannot reach.Changes
Shell / apps (this repo)
crates/shell/src/launch_input.rs(new): the one reader ofMAKEPAD_APP_CONFIG.honouredkeys oncfg(native_mobile)— a phone gates ondev_mode, a desktop always reads.run_test_actions, Mail'smail_demoandapps::module_opengo through it. A test checks no other shell source reads the variable directly.apps/appcard(opt-in): everyMAKEPAD_*hook goes throughlaunch_var/launch_flag, with the same desktop/phone split (launch_set_in(mobile, development, …)). Launch-time provisioning never applies in a phone release build; the QR scan with its PIN is unchanged.crates/kernel: the Android launch proxy (makepad.OCTOS_PROXY) applies only in a development build.dev-modefeature onoctosense-kernel,octosense-ai-host,octosense-appcardandoctos-app, forwarded from the shell'sdev-mode.Makepad (companion PR + stacked runtime patch)
The Studio connection (
makepad.STUDIO_HOST/STUDIO_CRATE) and theOCTOS_PROXYJVM proxy are things Makepad itself acts on, so they are gated in the Makepad fork: OctoSense-org/makepad#119 honours them from launch input only when the build opts into launch-time development input (debuggable, or the manifest meta-datadev.makepad.LAUNCH_STUDIO), never persists Studio settings in a non-debuggable app, and clears any already saved. To protect a release Home now, without waiting for a makepad sweep, the same change is carried here as the next stacked runtime patch (tools/runtime-patches/makepad-launch-input-hardening.patch) over the pinned makepad base. (The OpenHarmony part of #119 is not carried here — Home builds its own OpenHarmony entry ability, already gated.)Test builds and docs
rom/scripts/build-home.py --dev-mode(App Studio's, App Studio on the phone (ADR 0006 milestone 1): #313 rebased, reviewed, re-validated #477) builds thedev-modefeature: standalone only, never the installed Home's identity under its signer, and refused by ROM staging. Give it a test--package-name dev.makepad.octosense.<suffix>. OpenHarmony:build-home-ohos.py --dev-modebuilds a development HAP, which needs its own--bundle-id.cargo run. English and Chinese together.AGENTS.mdstates the desktop/phone split.Testing
launch_input::tests(a phone release/store build ignorestest_actions; a desktop build in every profile and a phone development build read them; malformed input; single reader),launch::tests::only_a_development_build_takes_the_launch_proxy(kernel), AppCardlaunch_input_tests,rom/tests/test_home_build.py(OpenHarmonyLaunchParameterTests; the Android--dev-moderules are App Studio on the phone (ADR 0006 milestone 1): #313 rebased, reviewed, re-validated #477's tests). The makepad gate decision is unit-tested in Repin the runtime to makepad 4531e695 (terminal tabs and fonts, system font fallback) #119 (app_main::tests::only_debuggable_or_opted_in_builds_honour_launch_dev_input).tools/ci-local.sh --only desktop,phone,apps --linux-host --offloadon the branch head: see the local-CI comment. Covers the shell tests withmobile-appsfromphone/(the newlaunch_inputtests ran there), the opt-in AppCard tests, the kernel tests, AppCard clippy-D warnings, and the desktop/Homecargo checklines.cargo test -p octos-app(not in CI) on the Linux build host: passes.romunit tests (JDK 17),generate-agent-aidl.py --check, the workflowbash -nlines,tools/unittests,setup.py --check --cargo,native_apps.py --check, andbuild-home.py --dev-mode … --dry-run.cargo test -p makepad-platform --lib app_mainandcargo check --target aarch64-linux-android -p makepad-platform.setup.pyreproduces it).--dev-modeAPK or HAP built (the Android plan was checked with--dry-run); no GUI run. The Java and ArkTS changes in Repin the runtime to makepad 4531e695 (terminal tabs and fonts, system font fallback) #119 are not exercised here.Rebased onto #477
#477 (App Studio) landed first with its own
build-home.py --dev-mode, so this PR was rebased onto it (main 0209df1):crates/shell/src/apps.rskeeps both: Studio's instance launch, thenlaunch_input::app_config().rom/scripts/build-home.pyis App Studio on the phone (ADR 0006 milestone 1): #313 rebased, reviewed, re-validated #477's. This PR's own--dev-modedesign was dropped: Home alone,--app-label,out/home/dev/. ItsDevelopmentPackageTestswere dropped with it, and the docs now name App Studio on the phone (ADR 0006 milestone 1): #313 rebased, reviewed, re-validated #477's flags and output path. The security change doesn't depend on it: thedev-modefeature gates launch input in code, and App Studio on the phone (ADR 0006 milestone 1): #313 rebased, reviewed, re-validated #477 already keeps adev-modebuild off the installed Home's identity.Note for merge
This PR touches
rom/, so the two-run local-CI gate applies; the coordinator runs it.🤖 Generated with Claude Code