modifier
Modifier for the dialog.
A simulated radio, selected as "Demo Mode" in the Connections screen.
It answers the app's real two-stage want_config handshake and then feeds a small synthetic mesh — a populated node list with positions, signal readings and battery levels, one channel conversation, one direct-message thread, and telemetry that keeps accruing while the app is open. That makes the app fully explorable without any LoRa hardware, which is what an app-store reviewer and a first-time user both need.
Three properties of the real protocol have to be honoured or the app never leaves "Loading node list":
The handshake is two-stage (HandshakeConstants.CONFIG_NONCE then HandshakeConstants.NODE_INFO_NONCE). Each stage must answer with only its own frames and its own config_complete_id. Re-sending my_info on stage 2 resets the app's handshake state machine and the stage-2 completion is then rejected.
node_info frames are only accepted inside the handshake window, so every simulated node has to ship in stage 2.
Radio metrics (SNR/RSSI/hops) are only taken from packets that look like direct LoRa receptions — transport_mechanism = TRANSPORT_LORA and hop_start == hop_limit. Frames left at the proto defaults are treated as internal traffic and contribute no signal information at all.
A simulated radio, selected as "Demo Mode" in the Connections screen.
It answers the app's real two-stage want_config handshake and then feeds a small synthetic mesh — a populated node list with positions, signal readings and battery levels, one channel conversation, one direct-message thread, and telemetry that keeps accruing while the app is open. That makes the app fully explorable without any LoRa hardware, which is what an app-store reviewer and a first-time user both need.
Three properties of the real protocol have to be honoured or the app never leaves "Loading node list":
The handshake is two-stage (HandshakeConstants.CONFIG_NONCE then HandshakeConstants.NODE_INFO_NONCE). Each stage must answer with only its own frames and its own config_complete_id. Re-sending my_info on stage 2 resets the app's handshake state machine and the stage-2 completion is then rejected.
node_info frames are only accepted inside the handshake window, so every simulated node has to ship in stage 2.
Radio metrics (SNR/RSSI/hops) are only taken from packets that look like direct LoRa receptions — transport_mechanism = TRANSPORT_LORA and hop_start == hop_limit. Frames left at the proto defaults are treated as internal traffic and contribute no signal information at all.
Reusable Robolectric helpers for driving Android Bluetooth bonding logic in androidHostTest source sets.
These let a unit test exercise the real AndroidBluetoothRepository.bond() (and any future BLE bonding code) without an emulator and without a production seam. They rely on two Robolectric behaviors (verified against Robolectric 4.16.x):
android.bluetooth.BluetoothAdapter.getRemoteDevice caches the returned BluetoothDevice by address in a static map, so the shadow configured here is the same instance production code reads when it calls getRemoteDevice(mac) internally.
ShadowBluetoothDevice.createBond calls checkForBluetoothConnectPermission() first, so tests must call grantBluetoothConnectPermission or createBond() throws SecurityException instead of returning a value.
Isolation note: because the device cache is static and survives across tests in the same JVM, give each test a distinct MAC so bond-state cannot bleed between tests.
Reusable Robolectric helpers for driving Android Bluetooth bonding logic in androidHostTest source sets.
These let a unit test exercise the real AndroidBluetoothRepository.bond() (and any future BLE bonding code) without an emulator and without a production seam. They rely on two Robolectric behaviors (verified against Robolectric 4.16.x):
android.bluetooth.BluetoothAdapter.getRemoteDevice caches the returned BluetoothDevice by address in a static map, so the shadow configured here is the same instance production code reads when it calls getRemoteDevice(mac) internally.
ShadowBluetoothDevice.createBond calls checkForBluetoothConnectPermission() first, so tests must call grantBluetoothConnectPermission or createBond() throws SecurityException instead of returning a value.
Isolation note: because the device cache is static and survives across tests in the same JVM, give each test a distinct MAC so bond-state cannot bleed between tests.
A comprehensive and flexible dialog component for the Meshtastic application.
Modifier for the dialog.
The title text of the dialog.
The title string resource of the dialog.
Optional plain text message.
Optional string resource message.
Optional color for the plain text message; Color.Unspecified uses the default text color.
Optional HTML formatted message.
Optional leading icon.
Optional custom composable content for the body.
Text for the confirmation button.
String resource for the confirmation button.
Callback for the confirmation button.
Text for the dismiss button.
String resource for the dismiss button.
Callback for when the dialog is dismissed or the dismiss button is clicked.
If provided, displays a list of buttons instead of the standard confirm/dismiss actions.
Whether the dialog can be dismissed by clicking outside or pressing back.
A comprehensive and flexible dialog component for the Meshtastic application.
Modifier for the dialog.
The title text of the dialog.
The title string resource of the dialog.
Optional plain text message.
Optional string resource message.
Optional color for the plain text message; Color.Unspecified uses the default text color.
Optional HTML formatted message.
Optional leading icon.
Optional custom composable content for the body.
Text for the confirmation button.
String resource for the confirmation button.
Callback for the confirmation button.
Text for the dismiss button.
String resource for the dismiss button.
Callback for when the dialog is dismissed or the dismiss button is clicked.
If provided, displays a list of buttons instead of the standard confirm/dismiss actions.
Whether the dialog can be dismissed by clicking outside or pressing back.
The Material 3 search bar every Meshtastic search field is built from: a collapsed SearchBar that expands into a results surface over the screen.
The expanded half follows Material's own rule rather than the caller's: full-screen on compact width, docked on anything wider, because a full-screen dialog over a tablet or desktop window hides context the user was reading.
the text the field starts with, so a query that survived process death restores into the bar. Later changes to it are ignored; the field is the source of truth once it exists. See resetKey.
called for every edit made through the field.
shown in the empty field, and the field's accessibility name.
change this to make the field take query again, for a caller that clears the search from outside.
test tag for the collapsed field; the expanded one takes it plus SEARCH_BAR_EXPANDED_TAG_SUFFIX.
lets the bar react to the content scrolling under it; see SearchBarDefaults.enterAlwaysSearchBarScrollBehavior.
extra icons after the clear button, for controls that belong to the search itself (a sort menu, a filter menu). They render in the collapsed and expanded field alike.
the results shown under the field once expanded.
The Material 3 search bar every Meshtastic search field is built from: a collapsed SearchBar that expands into a results surface over the screen.
The expanded half follows Material's own rule rather than the caller's: full-screen on compact width, docked on anything wider, because a full-screen dialog over a tablet or desktop window hides context the user was reading.
the text the field starts with, so a query that survived process death restores into the bar. Later changes to it are ignored; the field is the source of truth once it exists. See resetKey.
called for every edit made through the field.
shown in the empty field, and the field's accessibility name.
change this to make the field take query again, for a caller that clears the search from outside.
test tag for the collapsed field; the expanded one takes it plus SEARCH_BAR_EXPANDED_TAG_SUFFIX.
lets the bar react to the content scrolling under it; see SearchBarDefaults.enterAlwaysSearchBarScrollBehavior.
extra icons after the clear button, for controls that belong to the search itself (a sort menu, a filter menu). They render in the collapsed and expanded field alike.
the results shown under the field once expanded.
Og2)qzk}t7;8{C3OwT{)g{o|x$SHU`06Rw<6^+;p|Y?N@q%_R+=9}wEu2$V2&Hu>
zgONW7Gy4$>OigL#Tf7BOnJ+D|sBrxOce7a1H8Yiaw;A=D9x^Ia#k!N(8
Located in commonTest or jvmTest source sets.
Uses Android Gradle Plugin’s native (layoutlib) screenshot testing framework, split across two modules:
validateDebugScreenshotTest on it; reframing one of these baselines is a real diff to review. Holds atomic, dual-purpose components../gradlew :screenshot-tests:updateDebugScreenshotTest # record regression goldens
+Located in commonTest or jvmTest source sets.
Uses Android Gradle Plugin’s native (layoutlib) screenshot testing framework, split across two modules:
:screenshot-tests — the visual-regression gate. CI runs validateDebugScreenshotTest on it; reframing one of these baselines is a real diff to review. Holds atomic, dual-purpose components.:docs-screenshots — generate-only, not validated in CI. Holds doc-framed compositions whose framing is tuned for the docs site, so reframing a doc image never churns the regression gate../gradlew :screenshot-tests:updateDebugScreenshotTest # record regression goldens
./gradlew :screenshot-tests:validateDebugScreenshotTest # compare against goldens (CI gate)
./gradlew :docs-screenshots:updateDebugScreenshotTest # record doc-framed composition images
./gradlew :screenshot-tests:copyDocsScreenshots # copy doc images from BOTH modules into docs/assets
-Rendering is host-deterministic here (layoutlib): a local update produces references byte-identical to CI, so locally-recorded goldens pass validate. See docs/assets/screenshots/README.md for which module a new screenshot belongs in.
The store-listing screenshots (Play, F-Droid, IzzyOnDroid, and the desktop app’s Flathub listing) are generated too, by a third module: 0 is a plain JVM program, not a test. It renders the app’s own commonMain screens offscreen with Compose Desktop’s ImageComposeScene over one sample mesh and captures the real MapLibre map (basemap plus the app’s node chips) through maplibre-compose’s MapSnapshotter. Every shot is the raw screen, as Play’s listing rules require - no device frame, no caption banner - at one size per form factor. It has no tests, so ./gradlew test never touches it, and CI never runs it. The one command:
./gradlew :marketing-screenshots:updateMarketingScreenshots
-That writes 1_messages.png … 5_channels.png into five folders under fastlane/metadata/android/en-US/images/, and meshtastic-desktop-01-nodes.png … meshtastic-desktop-05-settings.png into the Flathub folder, reproducibly - the screens are byte-identical between runs; a wide map can differ by a few antialiased label-edge pixels, see below:
| Folder | Size | Window | Uploaded by |
|---|---|---|---|
phoneScreenshots/ | 1080×1920 @2.5x | 432×768 dp, compact: bottom navigation bar | fastlane supply |
sevenInchScreenshots/ | 1080×1920 @1.8x | 600×1067 dp, medium: navigation rail, one pane | fastlane supply |
tenInchScreenshots/ | 2560×1440 @2x | 1280×720 dp, expanded: rail, list beside detail | fastlane supply |
chromebookScreenshots/ | 1920×1080 @1x | expanded | hand, in Play Console |
xrScreenshots/ | 1920×1200 @1x (8:5) | expanded | hand, in Play Console |
desktopApp/packaging/linux/screenshots/ | 1280×800 @1x (16:10) | expanded: rail, list beside detail | Flathub, through metainfo.xml |
The screens are composed in the app’s own adaptive shell (NavigationSuiteScaffold, ListDetailPaneScaffold, AdaptiveTwoPane) with the same window-class calculations the app uses, so the form factors are data - a size, a density, a shot list and an output folder in FormFactor.kt - and every layout difference between them is the app’s own. Neither fastlane supply nor the Play Developer API has a Chromebook or XR slot, so those two folders are ignored by supply and F-Droid and uploaded by hand. The desktop set lists nodes, messages, map, connections and settings, the five <screenshot> entries in desktopApp/packaging/linux/org.meshtastic.MeshtasticDesktop.metainfo.xml, whose <image> URLs name the PNGs attached to that version’s GitHub release (releases/download/v<version>/), because Flathub takes screenshot links from a tag, a commit or a release, never a branch. The release pipeline renders the set on every internal cut, attaches it to the release, publishes it to the Play listing on production, and opens a self-merging PR that writes it back here (RELEASE_PROCESS.md); a hand run is for previewing a change before it ships, and the VERSION_NAME_BASE bump moves the five URLs to the next version. The basemap is the app’s default Liberty style, labels included. MapLibre packs glyphs into an atlas in tile-arrival order, so on the wide layouts a label’s antialiased edge can land one level off between generations - a dozen pixels, invisible; the generator captures from fresh runtimes until two agree and warns if they never do, and a regenerated wide map may not cmp the previous one. Commit whichever run produced it.
Locales: -PmarketingLocales=en-US,de-DE renders each locale in turn after switching the JVM default locale, the same switch the desktop app makes, so the app’s strings, numbers and dates follow. Only en-US goes into fastlane/ - everything there is read straight from git by F-Droid and IzzyOnDroid - and every other locale lands in marketing-screenshots/build/marketing-screenshots/<locale>/images/ in the same layout, ready for a later supply run, with the desktop set beside it in <locale>/desktop/. The sample prose (the thread, the conversation previews, the framed variant’s captions) is in marketing-screenshots/src/main/composeResources/values/strings.xml, which crowdin.yml’s first rule already globs like every other composeResources strings file, so a translated conversation needs no configuration change; until Crowdin fills a locale’s values-xx/strings.xml, that locale’s chat text stays English while the UI around it is translated.
-PmarketingFramed=true also writes the framed 1242×2484 phone variants - bezel, drawn status bar and a caption banner - under marketing-screenshots/build/marketing-screenshots/framed/<locale>/, for the website and social posts. They never go into fastlane/.
The map needs a Vulkan loader the JVM can find. On a stock Ubuntu nothing is required; in a Nix dev shell, which replaces LD_LIBRARY_PATH on entry, pass -PmarketingLibraryPath=/usr/lib/x86_64-linux-gnu (the system loader plus the GPU’s ICD). No display is needed or used.
The :baselineprofile module (#5735) generates a Baseline Profile for :androidApp, AOT-compiling the hot startup paths so ART doesn’t pay the JIT cost on first launch. It targets the google flavor (the variant most users run).
The Macrobenchmark generator (BaselineProfileGenerator) and the before/after benchmark (StartupBenchmark) live in baselineprofile/src/main/kotlin/org/meshtastic/baselineprofile/. Both run on a device/emulator:
./gradlew :androidApp:generateGoogleReleaseBaselineProfile # Generate the profile (commit the output)
+Rendering is host-deterministic here (layoutlib): a local update produces references byte-identical to CI, so locally-recorded goldens pass validate. See docs/assets/screenshots/README.md for which module a new screenshot belongs in.
The store-listing screenshots (Play, F-Droid, IzzyOnDroid, and the desktop app’s Flathub listing) are taken from the real apps, connected to Demo Mode’s hidden showcase mesh (/connections?address=mshowcase, MockScenario.SHOWCASE in :core:network), rather than drawn. Every screen is reached by its deep link, so the flow does not depend on the display language, and each shot is kept once the window has stopped changing.
:store-screenshots, a UiAutomator 2.4 test module targeting :androidApp. For each surface fastlane supply uploads it sets the display size and density, relaunches the debug app through its shell-only AutomationLauncher alias with skip_onboarding and skip_connect_confirm, and saves the five listing shots, full screen with a SystemUI demo-mode status bar, to /data/local/tmp/store-screenshots on the device.store-screenshots/capture-desktop.sh runs the real desktop debug build on an Xvfb display, one launch per screen with that screen’s deep link, and saves the five Flathub shots. The map needs Skiko’s OpenGL renderer and Skiko refuses any GL adapter named llvmpipe or virgl, so Mesa runs GL through zink over lavapipe.On an emulator or device, one flavor at a time:
./gradlew :store-screenshots:connectedFdroidDebugAndroidTest
+adb pull /data/local/tmp/store-screenshots/. fastlane/metadata/android/en-US/images/
+| Folder | Size | Window | Uploaded by |
|---|---|---|---|
phoneScreenshots/ | 1080×1920 @400 dpi | compact: bottom navigation bar | fastlane supply |
sevenInchScreenshots/ | 1080×1920 @288 dpi | medium: navigation rail, one pane | fastlane supply |
tenInchScreenshots/ | 2560×1440 @320 dpi | expanded: rail, list beside detail | fastlane supply |
desktopApp/packaging/linux/screenshots/ | 1280×800 | expanded: rail, list beside detail | Flathub, through the release assets metainfo.xml names |
.github/workflows/store-screenshots.yml runs both on hosted runners, per flavor for Android (google for the Play listing, fdroid for the committed tree), on every internal release, on demand, and on pull requests that touch the renderer or the showcase mesh. The release pipeline attaches the captures to the release, publishes the Play listing from them on production, and opens a self-merging PR that writes the fdroid and desktop sets back here (RELEASE_PROCESS.md).
The :baselineprofile module (#5735) generates a Baseline Profile for :androidApp, AOT-compiling the hot startup paths so ART doesn’t pay the JIT cost on first launch. It targets the google flavor (the variant most users run).
The Macrobenchmark generator (BaselineProfileGenerator) and the before/after benchmark (StartupBenchmark) live in baselineprofile/src/main/kotlin/org/meshtastic/baselineprofile/. Both run on a device/emulator:
./gradlew :androidApp:generateGoogleReleaseBaselineProfile # Generate the profile (commit the output)
./gradlew :androidApp:benchmarkGoogleReleaseBaselineProfile # Quantify the cold-start win
The generated profile is merged into androidApp/src/googleRelease/generated/baselineProfiles/ and packaged into release builds via androidx.profileinstaller.
ℹ️ Note: The journey covers cold start only (launch → first frame), because CI has no paired node. Post-connection screens (node list, map, message thread) aren’t yet AOT-compiled.
Extending the journey past cold start needs a fake transport or a connected node wired into the harness.
feature/my-feature/src/
├── commonTest/kotlin/org/meshtastic/feature/myfeature/
diff --git a/main/index.json b/main/index.json
index 1b1bdc75ec..6437687a45 100644
--- a/main/index.json
+++ b/main/index.json
@@ -29,7 +29,7 @@
{"id":"navigation-and-deep-links","title":"Navigation & Deep Links","section":"developer","locale":"en","resourcePath":"docs/developer/navigation-and-deep-links.html","navOrder":4,"keywords":["navigation", "deep", "links", "route", "architecture", "hierarchy", "conventions", "link", "router", "uri", "format", "supported", "backstack", "synthesis", "adding", "entry", "registration", "testing"],"aliases":["deeplinks", "navigation-3", "routes"],"charCount":8296},
{"id":"persistence","title":"Persistence","section":"developer","locale":"en","resourcePath":"docs/developer/persistence.html","navOrder":6,"keywords":["persistence", "room", "kmp", "database", "key", "points", "what", "stored", "datastore", "preferences", "core", "prefs", "docs", "intentionally", "skip", "best", "practices"],"aliases":["room", "database", "datastore", "prefs"],"charCount":3670},
{"id":"test-builds","title":"Test Builds & Obtainium","section":"developer","locale":"en","resourcePath":"docs/developer/test-builds.html","navOrder":10,"keywords":["test", "builds", "obtainium", "which", "channels", "can", "reach", "one", "tap", "setup", "how", "many", "entries", "you", "have", "once", "manual", "stable", "open", "beta", "closed", "bleeding", "edge", "newest", "promoted", "build", "any", "channel", "snapshot", "latest"],"aliases":["test-builds", "obtainium", "beta", "snapshot"],"charCount":20778},
- {"id":"testing","title":"Testing","section":"developer","locale":"en","resourcePath":"docs/developer/testing.html","navOrder":7,"keywords":["testing", "test", "categories", "kmp", "unit", "tests", "commontest", "android", "host", "compose", "screenshot", "baseline", "profile", "startup", "performance", "organization", "guidelines", "don", "running", "all", "specific", "module", "code", "quality", "full", "verification", "integration"],"aliases":["tests", "unit-tests", "screenshot-tests"],"charCount":10221},
+ {"id":"testing","title":"Testing","section":"developer","locale":"en","resourcePath":"docs/developer/testing.html","navOrder":7,"keywords":["testing", "test", "categories", "kmp", "unit", "tests", "commontest", "android", "host", "compose", "screenshot", "baseline", "profile", "startup", "performance", "organization", "guidelines", "don", "running", "all", "specific", "module", "code", "quality", "full", "verification", "integration"],"aliases":["tests", "unit-tests", "screenshot-tests"],"charCount":7660},
{"id":"transport","title":"Transport","section":"developer","locale":"en","resourcePath":"docs/developer/transport.html","navOrder":5,"keywords":["transport", "abstraction", "bluetooth", "low", "energy", "ble", "where", "the", "code", "lives", "usb", "serial", "tcp", "factory", "connection", "lifecycle", "adding", "new"],"aliases":["ble", "serial", "tcp", "radio-transport"],"charCount":4902},
{"id":"app-functions","title":"App Functions","section":"user","locale":"ar-rSA","resourcePath":"docs/ar-rSA/user/app-functions.html","navOrder":19,"keywords":["app", "functions", "enabling", "write", "read", "privacy", "related", "topics"],"aliases":["app-functions", "system-ai", "gemini", "assistant"],"charCount":4364},
{"id":"connections","title":"Connections","section":"user","locale":"ar-rSA","resourcePath":"docs/ar-rSA/user/connections.html","navOrder":2,"keywords":["connections", "bluetooth", "ble", "pairing", "radio", "connection", "status", "troubleshooting", "usb", "serial", "setup", "tcp", "network", "connecting", "over", "the", "when", "use", "provisioning", "for", "mpwrd", "after", "your", "first", "reconnection", "behavior", "desktop", "related", "topics"],"aliases":["bluetooth", "usb", "tcp", "pairing"],"charCount":11132},