DEV Community: Roronoa

Keep Partial Transcripts Out of Crash Upload Payloads

Roronoa — Thu, 24 Sep 2026 18:22:57 +0000

You join the voice-notes repo on a Monday morning, and the open bug is already older than your laptop setup. The on-device recognizer drops the last partial utterance when an incoming phone call kills the app process. In the first hour you add a crash breadcrumb that stores that partial text so the next fatal error is easier to explain. By the afternoon that same string sits inside a vendor upload collected from the shared QA phone on the desk.

This opening is a proposed failure path, not a measurement taken from a named handset anywhere in this article. You should treat every version, permission bit, and power state below as a field you fill on your own device. The goal is to stop your first pull request from teaching the crash pipeline how to remember spoken content. A redacted breadcrumb can still explain the process death without copying the utterance into the outbound upload.

What you inherit in the first hour

Separate this leak from older ones

You are not retesting keyboard learning, phone backup, recents capture, or the remote debug host during this pass. Those leaks need their own experiments, and mixing them in one matrix hides which control actually failed. This pass covers crash breadcrumbs, native tombstones, and the log buffer that a reporter attaches after the process dies. If a unique sentence can be rebuilt from any of those three places, the first-hour patch is not finished.

Write the environment header first

Write the device model, OS build, framework version, and crash SDK version at the top of your notes. Also record microphone permission, network type, and whether the phone is on battery saver or wall power. A junior rollback is safer when that header remains in the pull request after the diff has already moved. Without the header, the next person cannot separate a scrub failure from an OS change they never reproduced.

Decide what a breadcrumb may keep

Use a contract, not a vibe

Use the table as the contract for the first pull request, and review every row before you add an SDK call. It is a review aid, not a claim that every crash vendor behaves the same way on every OS build. If your pinned SDK disagrees with a row, follow the current vendor guide and record that exception in the pull request. Do not copy an older sample that attaches the raw message string just because a tutorial did that last year.

Field	Allowed in crash payload	Reason
Partial transcript text	No	Speech content is user data, even when recognition ran on device.
Transcript length bucket	Yes, coarse only	Empty, short, or long helps triage without storing words.
Locale tag	Yes	Language id explains model choice and does not reveal the utterance.
Model package id	Yes, if non-secret	Identifies the on-device bundle you shipped, not the audio.
Audio bytes or file path	No	Paths often include user ids, and bytes are the recording itself.
Permission state at crash	Yes	Revoked versus granted microphone changes the expected failure.
Lifecycle transition	Yes	Background, call interruption, or low-power entry is the variable.
Exception class and stack	Yes, after scrub	Keep the type, and drop messages that echo the utterance.

When support asks for the words

If a teammate says support cannot debug the death without the words, move that debate out of the first hour. Ship the redacted payload first, then design a consented debug build that never ships on the public store track. A store build that sometimes includes speech is harder to roll back than a flag that never attached the text. Keep the debate in the ticket, and keep the words out of the payload while the team waits for a decision.

Build the breadcrumb in one place

Proposed Kotlin scrub

Put the scrub in one function so a later feature cannot invent a second logger that still holds the raw text. The Kotlin snippet below is proposed example code, and you should rename the types to match the crash SDK you link. It has not been timed on a device for this article, so do not read it as a latency or battery result. Run it only after you confirm the method names against the SDK version pinned in your dependency lockfile.

data class VoiceCrashCrumb(
    val lengthBucket: String,
    val locale: String,
    val modelPackageId: String,
    val micGranted: Boolean,
    val lifecycle: String,
    val errorClass: String,
)

fun lengthBucket(partial: String?): String = when {
    partial.isNullOrEmpty() -> "empty"
    partial.length < 40 -> "short"
    partial.length < 160 -> "medium"
    else -> "long"
}

fun voiceCrumb(
    partial: String?,
    locale: String,
    modelPackageId: String,
    micGranted: Boolean,
    lifecycle: String,
    error: Throwable,
): VoiceCrashCrumb {
    // Never pass partial or error.message into the SDK map.
    return VoiceCrashCrumb(
        lengthBucket = lengthBucket(partial),
        locale = locale,
        modelPackageId = modelPackageId,
        micGranted = micGranted,
        lifecycle = lifecycle,
        errorClass = error::class.java.simpleName,
    )
}

Register the same rule on iOS and cross-platform shells

Never pass the partial string or the exception message into the map that the crash SDK will serialize and send. On iOS, apply the same rule to every custom key you set before the reporter builds its outbound payload. Metric and diagnostic APIs differ by OS version, so read the guide that matches the SDK version you actually link. If that SDK offers a log scrubber callback, register it beside the crumb builder rather than in a random extension.

A second registration point is how the first rollback leaves one path still attaching speech after the flag looks off. Search the repo for the partial variable name before review, including instrumentation tests and leftover sample activities. A unit test that asserts the serialized map lacks that variable is worth more than a comment about being careful. Add the test in the same pull request so a rollback cannot delete the only guard you had.

If you are in React Native or Flutter, keep the scrub on the native crash bridge, not only in the Dart or JavaScript logger. A redacted JS breadcrumb does nothing once the native module still forwards the utterance in its own map. Name that bridge method in the pull request so the reviewer knows which side you actually changed. Cross-platform shells fail this test when only one language was searched for the partial string before review.

Run the first-hour experiment

Follow one order

The steps below are a procedure for you to run, not a result reported from a lab phone in this article. Fill the environment header, follow the order, and stop when the payload still contains the unique synthetic sentence. A pass on a plugged-in phone does not prove the same scrub under battery saver or after a microphone revoke. Those transitions belong in this pull request because they are how on-device voice sessions actually die in the field.

Record device model, OS version, app version, crash SDK version, network type, battery saver state, and microphone permission before you start.
Install a debug build that calls the crumb builder, and keep any raw logger behind a flag that defaults to off.
Speak a unique synthetic sentence that appears nowhere else in the repo, using an animal name plus a four-digit code.
Force a crash from the voice screen after the partial text is visible, using the test hook you already ship for QA.
Collect the local crash file or the debug upload, then search for that sentence, the raw partial, and the exception message.
Repeat the crash once after you background the app, and once after you revoke the microphone and return to the same screen.
Toggle airplane mode before the reporter flushes, restore the network, and search the retried payload for the same sentence.
Confirm the payload still has the length bucket, locale, model package id, permission bit, lifecycle label, and exception class.

Capture commands you can adapt

Replace the sample package name, and do not collect logcat from a phone that already holds real user audio from customers. If the search tool in the sample is missing on your host, use grep with the same pattern and paste the command into the pull request. On a shared QA phone, clear the log buffer before the run so an older session cannot masquerade as a fresh pass. A dirty buffer is the usual reason a junior marks the scrub finished while yesterday's sentence is still sitting there.

adb shell getprop ro.build.version.release
adb shell dumpsys package com.example.voicenotes | grep -i permission
adb logcat -c
adb logcat -d -t 200 | grep -E "transcript|voiceCrumb|PARTIAL"

Record the iOS outcome separately

iOS needs a different capture path, because Console and the crash reporter do not share a single ring buffer. Export the pending report from the device, or open the SDK debug viewer, then search for the same unique sentence. Write whether that report recovered after relaunch, restarted as a new session, or silently disappeared from the pending queue. Keep that observation next to the Android notes, and do not invent a battery figure to make the two platforms look comparable.

Roll back without restoring the leak

Your first rollback should disable the flag that attaches breadcrumbs, not delete the scrub function from the module. If the redacted crumb crashes inside the crash SDK, turn attachment off and keep forbidden fields out of every other logger. Do not fix a bad upload by putting the raw partial back while you wait for a vendor support reply. That shortcut becomes the next release incident, and it is harder to see because the flag was described as temporary.

A rollback note in the pull request can stay this concrete:

The attachment flag defaults to false on the store track, and a debug build may enable it only after the unique-sentence search passes.
Reverting that flag does not revert the rule that partial text never enters the upload map, the log line, or the native message.
If QA needs the words, they use a local-only overlay that the release build compiles out, rather than a hidden gesture in production.

If the flag-off build still uploads the sentence, the leak sits outside this patch and needs a wider search before you blame the crumb. Check analytics events, native standard error, and any attach-log checkbox that the reporter settings screen still leaves enabled. Also search for string interpolation that builds a log line before your scrub function has a chance to run. The first hour is long enough to miss a debug print that a sample activity left behind during the previous sprint.

Draft fixtures away from production speech

You will want synthetic utterances and a second reading of the scrub rules before you open the first pull request. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode's free model access and free server option can host that drafting when you paste only synthetic sentences and the redaction function. Do not paste customer audio, device logs, or crash archives just because that server is free and the first hour feels short.

This article does not name a model, a token quota, a machine shape, or a duration you should plan a release around. An allowance you remember from an older post is not evidence, so treat the live limit as unknown until the project page states it. If the project publishes a repository or a pricing note, read that page yourself rather than trusting a recap from chat. Use the free model access on the free server to generate length-bucket cases from invented sentences only.

Then ask whether a proposed log line still holds recoverable speech, after you confirm the current terms on the project page. If your workplace forbids external code tools, skip the drafting server and review the contract table with a teammate on your own network. The handset experiment still stands on its own, and a local review is enough to open a careful first pull request. A free server is only a convenience for synthetic fixtures, not a store for the speech this patch is trying to keep on device.

Who should skip this pattern

Skip this pattern when you must retain verbatim speech for a medical, legal, or accessibility record inside an already approved system. Also skip it when the crash SDK cannot attach custom keys without also capturing the full log buffer on that OS version. In that case the first pull request should disable log attachment, rather than encode the sentence into a clever numeric bucket. A one-character length bucket is the transcript with extra steps, and review should reject that encoding as a leak.

Employee debug screens can remain when they are local-only and compiled out of the release variant you actually ship. They must not call the upload API, even behind a hidden gesture that the QA group believes nobody outside the team will find. Hidden gestures leak because crash reporters and screen recordings both outlive the person who added them during onboarding. If you need consented capture, put it in a separate build flavor whose name a reviewer cannot miss in the diff.

What you should send back

Reply with the device, the OS build, the crash SDK version, and the lifecycle step you actually executed on that hardware. Say whether the unique sentence recovered in a later upload, stayed only in the local log, or disappeared after the scrub. If you rolled the flag back, say whether the flag-off build still contained the sentence inside some other attachment. Those three outcomes are more useful than a vague note that the crash flow felt acceptable on your desk.

This article measured no handset, and vendor behavior changes with the SDK version you pin during the following week. A scrub that passes a logcat search can still fail inside a native minidump or an attached console export from the same run. Re-read the SDK notes for your exact dependency before you merge, and link that note from the pull request description. If you cannot name the device and the transition, you do not yet have a result, only a plan you still need to run.

A Secure Mobile Handoff for First-Hour Streaming Before Recents Capture

Roronoa — Wed, 23 Sep 2026 16:08:39 +0000

You clone the mobile AI repo on day one, and the onboarding doc tells you to send a test prompt before lunch. The assigned device is still in the foreground, microphone permission is granted, and the streaming view is painting tokens into a chat bubble. You switch apps to copy a ticket number, and the recents thumbnail still shows the last partial answer. An hour later your first rollback lands, yet that snapshot can remain on the device until the next cold start.

This article is a proposed first-PR checklist, not a measured lab report from a specific fleet. You should treat every command below as a starting procedure and record what your own device actually does. The goal is a secure handoff between on-device streaming and an optional sandbox host. You still must keep first-hour text out of Recents, accessibility captions, and leftover files after rollback.

What actually goes wrong in the first hour

A junior engineer usually debugs the happy path: a prompt goes in, tokens come out, and the ticket is marked done. Mobile operating systems do extra work whenever you leave the activity, and that work is not in the product spec. Recents capture, accessibility trees, log buffers, and backup-eligible cache files all sit outside your Compose or Flutter widget tree.

You also get pressure to just hit the cloud so the first demo looks smart. Production inference hosts are the wrong place for that first hour, because test prompts and device identifiers do not belong there. A sandbox host is only acceptable when the prompt is synthetic and the app redacts the payload before it leaves the process.

Typical first-hour leaks look like this:

Recents or App Switcher thumbnails still render the last streamed answer.
Android accessibility nodes expose the full token buffer to any bound service.
iOS snapshot APIs write a launch image that survives the next process death.
Debug builds print function-call JSON to logcat or the Xcode console.
A rollback restores an old binary but leaves cache files and the last thumbnail.

Proposed lab setup, labeled as unexecuted

Do not copy these versions as if they were measured results from this article. Write down the device you actually hold, including OS build and framework versions. Network, permission, and power state belong in the same note, because each one changes what the operating system captures. The lifecycle transition under test should be a single action, such as Home, Recents swipe, permission revoke, or uninstall.

Record before you type a prompt

Device and OS: Pixel 8a on Android 15, or iPhone 14 on iOS 18, as examples only
Framework: Android View or Compose, UIKit or SwiftUI, React Native, or Flutter, with exact versions
Network: Wi-Fi only, cellular only, or airplane mode with a local mock
Permissions: microphone, notifications, and accessibility, each granted or revoked
Power: plugged in, or battery saver / Low Power Mode enabled
Application state: cold start, warm start, or already streaming in the foreground
Lifecycle transition: Home button, Recents swipe, permission revoke, or uninstall rollback

Expected observations belong in your notes, not in this article as claimed numbers. You are looking for whether the answer recovered, restarted from a blank surface, or silently remained visible. If two teammates cannot name the same transition, they are not comparing the same bug.

The handoff you want on a first PR

You should keep first-hour streaming on-device unless a reviewer explicitly asked for a hosted comparison run. If you need a comparison host, point it at a disposable sandbox rather than the production AI endpoint. Redact the prompt, the tool-call JSON, and any device identifiers before the request is built. Blank the UI before the operating system takes a snapshot, then prove a later rollback deletes the cache.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode's free model access and free server option can serve as that disposable comparison host for non-production first-hour checks. They are not a privacy boundary, so you should still send only synthetic prompts from the debug build.

Decision table for the first-hour path

Condition	On-device path	Sandbox host path	Do not do this
Synthetic prompt, no account data	Allowed for local smoke	Allowed if URL is compile-time sandbox	Point at production
Real user paste or ticket text	Keep in memory only	Block the request	Log the raw string
Microphone buffer present	Stop capture on background	Do not upload the buffer	Attach audio to the comparison call
Permission revoked mid-stream	Cancel, clear surface	Cancel in-flight call	Retry against production
Recents / App Switcher	Privacy overlay or `FLAG_SECURE`	Same overlay still required	Trust the sandbox to hide UI
First rollback / uninstall	Delete cache and thumbnails	Drop sandbox tokens	Leave comparison URL in `SharedPreferences`

Android: stop Recents from painting tokens

The OS will screenshot your activity when the user leaves it, unless you opt out. FLAG_SECURE is the blunt instrument, and it also blocks intentional screenshots, so QA needs a debug toggle. A first PR should default the streaming activity to secure, then prove Recents no longer shows tokens. You should treat that proof as a device photograph, not as a glance at the emulator.

// Proposed snippet for the streaming Activity.
// Label: unexecuted example. Confirm against your minSdk and theme.

class StreamingActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        window.setFlags(
            WindowManager.LayoutParams.FLAG_SECURE,
            WindowManager.LayoutParams.FLAG_SECURE
        )
        setContentView(R.layout.activity_streaming)
    }

    override fun onStop() {
        streamingController.cancelAndClearSurface()
        logRedactor.dropTokenBuffer()
        super.onStop()
    }
}

You should also keep the task out of Recents when the first-hour debug build is only a scratch session. Leave the production manifest untouched until a reviewer asks for a persistent task. Debug overlays are the right place for excludeFromRecents, because a shipping chat screen still needs a normal recents entry after launch.

<!-- AndroidManifest.xml, debug overlay only -->
<activity
    android:name=".StreamingActivity"
    android:excludeFromRecents="true"
    android:autoRemoveFromRecents="true" />

For logcat, print a hash of the prompt rather than the prompt. Juniors often enable verbose OkHttp logging, and that is how function-call JSON leaves the phone. Strip query strings before any debug logger sees the request, even when the host is only a sandbox.

// Proposed interceptor. Unexecuted example.
class RedactingInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        val safeUrl = request.url.newBuilder()
            .encodedQuery(null)
            .build()
        Log.d("ai-handoff", "sandbox call ${request.method} ${safeUrl.encodedPath}")
        return chain.proceed(request)
    }
}

iOS: cover the window before the snapshot lands

UIKit takes a snapshot as you resign active, and that image can appear in App Switcher. A first-hour PR should install a cover view in sceneWillResignActive, then remove it on sceneDidBecomeActive. isSecureTextEntry helps for the prompt field, but it does not cover the answer transcript. Simulator App Switcher is not enough, because physical devices write snapshots on a different timing path.

// Proposed SceneDelegate hooks. Unexecuted example for iOS 17+.

func sceneWillResignActive(_ scene: UIScene) {
    streamingSession.cancelAndClear()
    PrivacyCover.install(on: window)
}

func sceneDidBecomeActive(_ scene: UIScene) {
    PrivacyCover.remove(from: window)
}

enum PrivacyCover {
    static let tag = 9001

    static func install(on window: UIWindow?) {
        guard let window, window.viewWithTag(tag) == nil else { return }
        let cover = UIView(frame: window.bounds)
        cover.tag = tag
        cover.backgroundColor = .systemBackground
        window.addSubview(cover)
    }

    static func remove(from window: UIWindow?) {
        window?.viewWithTag(tag)?.removeFromSuperview()
    }
}

If you use SwiftUI, hide the transcript with privacySensitive() and verify VoiceOver does not read the last answer after backgrounding. That check is easy to skip on a first PR because the happy path still looks correct in the simulator. Walk the VoiceOver cursor after pressing Home, and confirm the cover view is the only thing spoken.

Flutter and React Native: do not assume the plugin did it

Cross-platform shells often wrap a WebView or a platform view, and FLAG_SECURE is not automatic. You need a method channel, and you need to call it before the first token arrives, not after the user hits Home. A JavaScript-only overlay can lose the race against the OS snapshot, which means Recents still shows tokens. Put the secure-window call on the native side, then cancel the stream from the same lifecycle hook.

// Proposed Flutter channel. Unexecuted example.
const _secure = MethodChannel('handoff/secure_window');

Future<void> protectStreamingWindow() async {
  await _secure.invokeMethod('setSecure', true);
}

Future<void> clearStreamingWindow() async {
  await _secure.invokeMethod('setSecure', false);
}

// Android side of the same channel.
when (call.method) {
    "setSecure" -> {
        val enable = call.arguments as Boolean
        val window = activity.window
        if (enable) {
            window.addFlags(WindowManager.LayoutParams.FLAG_SECURE)
        } else {
            window.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)
        }
        result.success(null)
    }
}

// Proposed React Native AppState handler. Unexecuted example.
import { AppState, NativeModules } from 'react-native';

const { SecureWindow } = NativeModules;

function bindHandoff(streamingController) {
  const sub = AppState.addEventListener('change', (state) => {
    if (state === 'inactive' || state === 'background') {
      SecureWindow.setSecure(true);
      streamingController.cancelAndClearSurface();
    }
  });
  return () => sub.remove();
}

On React Native, confirm the overlay is not a JavaScript-only View, because the OS snapshot can race the JS thread. Call the native module first, then clear the in-memory token buffer. If the buffer still feeds a virtualized list, Recents can capture one extra frame after AppState says inactive.

Optional sandbox comparison, without a production host

When a reviewer asks whether on-device latency is even in the same band as a hosted model, you still should not open a production endpoint from a debug build. Put the comparison URL behind a debug flavor, and fail the build if a production host sneaks into that flavor. Cancel in-flight sandbox calls in onStop and sceneWillResignActive so a comparison request cannot outlive the UI. A request that outlives the UI is how first-hour text ends up in a server log you do not control.

// Proposed BuildConfig gate. Unexecuted example.
object InferenceHandoff {
    fun comparisonUrl(): HttpUrl? {
        check(BuildConfig.DEBUG) { "comparison host is debug-only" }
        val raw = BuildConfig.SANDBOX_INFERENCE_URL
        require(raw.contains("sandbox") || raw.contains("localhost"))
        return raw.toHttpUrl()
    }
}

# Proposed local check before you open the first PR.
# Replace the package name with yours.

adb shell dumpsys activity recents | grep -i streaming
adb logcat -d | grep -Ei "prompt=|content=|tool_call" && echo "FAIL: raw payload in logcat"

# iOS counterpart: inspect a physical-device screenshot, not only Simulator files.
# If tokens are visible, the cover view was installed too late.
xcrun simctl io booted screenshot /tmp/recents-check.png

Do not treat those commands as a pass/fail score for a device class. They only tell you whether this package, on this build, leaked a string or a thumbnail after one transition. Write the command output into the PR so a rollback review has evidence besides a demo GIF.

First rollback must delete more than the binary

Your first PR will get reverted. Rollback is not complete if Recents, cache, and the sandbox token remain. Add an uninstall-and-reinstall pass to the onboarding doc, and write the leftover paths into the PR template. Photograph Recents with a second device, because the phone you are testing cannot see its own thumbnail clearly.

Force-stop the app, then open Recents and photograph the thumbnail with a second device.
Revoke microphone permission while a stream is active, and confirm the surface clears.
Background the app, resume, and check whether tokens reappear without a new request.
Uninstall, reinstall the rolled-back build, and search app-specific storage for prompt files.
On Android, run adb shell pm clear <package> only on the engineering device, never on a shared dogfood phone.
On iOS, delete the app from Home Screen, then confirm Files / iCloud Drive has no leftover export.

# Android leftover hunt after rollback. Engineering device only.
adb shell run-as com.example.app ls -la cache/
adb shell run-as com.example.app ls -la files/

If any prompt-like file is still there, the first PR is not done. The rollback recovered the old binary, but the device did not recover a clean state. Say that explicitly in the PR so the next junior does not treat uninstall as optional cleanup.

Limitations, and who should not use this

FLAG_SECURE and App Switcher covers hide pixels; they do not encrypt memory. Accessibility services you granted for debugging can still read the tree unless you strip content descriptions on background. A sandbox host is shared infrastructure from your point of view as a junior, so real customer text does not belong there even when free model access is available for experiments.

You should not use this handoff if any of the following is true:

The prompt contains production user data, credentials, or health information.
Your team already forbids third-party inference hosts in debug builds.
You need screenshot-based QA of the streaming UI, and FLAG_SECURE would block that workflow without a documented debug toggle.
You are running on a shared device whose Recents or iCloud account you do not control.
You were about to treat latency numbers from one phone as a benchmark for a whole device class.

This procedure also does not prove battery cost, thermal throttling, or model quality. Those need separate measurements on named devices, and this article does not invent those numbers. A clean Recents thumbnail is a privacy check, not a performance result.

What to report back

If you run the checklist, write down the device, OS, framework versions, permission state, and the exact transition. Then say whether the streamed answer recovered, restarted from a blank surface, or silently stayed in Recents after rollback. Comparable environment evidence is more useful than a screenshot of a happy demo prompt.

Keep First-Hour Model Weights Out of Shared Storage After a Rollback

Roronoa — Tue, 22 Sep 2026 14:27:44 +0000

You clone the mobile AI sample onto a Pixel 8 running Android 15 with a fresh user profile. The app sits in the foreground on the first-run voice screen, waiting for a model file that is not packaged yet. Then you tap download, switch to another app, and later revert the pull request that added the fetch. Those model weights are still sitting on disk even though git status is completely clean again.

This is a proposed first-hour audit for a junior engineer joining a mobile AI repository, not a measured lab result. You should treat every download path as a lifecycle event that survives git revert, force-stop, and even uninstall in some cache layouts. The goal is simple: keep first-hour model weights out of shared storage after a rollback. Record the device, OS, framework versions, and one transition before anyone argues the device is clean.

Why a rollback is not a cleanup

A rollback restores source files, Gradle locks, and maybe a feature flag, but it does not restore the device. Android and iOS keep application caches, incomplete downloads, and media-store entries until you delete them on purpose. If the first PR wrote a .bin or .task file into Downloads, another app or a USB backup can still read it. Junior engineers often learn this only after a teammate restores a backup and finds a prototype speech model on the laptop.

Industry demos this week keep pushing live voice and small companion models onto devices that look charming in a video. Your first hour on a real phone is less charming, because the file you fetched to unblock a demo becomes durable state. Git cannot see cache/, Files/, or an iCloud-eligible container, so a green CI check after revert is not evidence of removal. You need a device-side audit that starts before the first byte lands.

What usually survives the first revert

Walk the filesystem with the same user profile you used for the download, not a second emulator that never ran the fetch. Then compare those paths against the rollback, because source control and storage have different lifetimes.

Incomplete HTTP bodies remain under cache/ when the user backgrounds the app during the first model download.
A DownloadManager or URLSession temp file can be promoted into shared storage after a process kill.
MediaStore or the Files app may index a .tflite or .bin you saved with a world-visible name.
Uninstall on Android can keep the cache if the user enabled backup, then a reinstall quietly restores weights.
iOS can include the file in an unencrypted Finder backup unless you excluded that directory from backup.

None of those rows is a battery number or a device-class claim. They are storage outcomes you can confirm or reject on one phone with listed OS and app versions. If you cannot name the directory, you cannot claim the rollback removed the model.

Record the environment before anyone hits download

Before any network call, write down device, OS, app state, permission state, and power state. You need those notes later when you argue that a rollback actually removed every on-device artifact. A junior PR that says “tested on my phone” without this block is not a mobile AI PR yet.

Copy this block into the pull request and fill it on the device, not from memory after lunch.

# Proposed first-hour device card (fill on device, do not invent later)
Device:           Pixel 8 / iPhone 14  (pick the one in your hand)
OS:               Android 15 / iOS 18.x
App state:        cold start, first-run, foreground voice screen
Lifecycle event:  download starts -> Home / app switcher -> git revert
Network:          Wi-Fi only / cellular / offline after airplane mode
Power:            charging / battery saver / Low Power Mode
Permissions:      microphone, notifications, photos — granted or denied
Framework:        Android Gradle Plugin, Kotlin, Flutter, or RN version
Expected:         no model file in Downloads, Photos, Files, or backup
Limitation:       single user profile, no MDM, no work profile

You are not collecting a benchmark here. You are collecting enough context that a reviewer can repeat the same transition tomorrow. If the OS build or the permission state is missing, stop and fill the card before the download starts.

Keep hour-one iteration off the phone

The fastest way to avoid leftover weights is to not download them during the first hour at all. Freeze the prompt contract, the JSON schema, and the timeout behavior against a remote development host, then package an on-device model only after that contract stops changing. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

If your team already uses MonkeyCode, free model access and a free server option can host that first-hour contract off the device. The mobile client then sends the same request shape without baking a long-lived vendor key into the binary. You still must not store that host token in logcat, in plaintext SharedPreferences, or in a committed local.properties file. This article does not claim model names, quotas, hardware, uptime, or permanence for that hosted option.

Use the remote host only as a contract gym. When the request and response shapes stabilize, you copy a frozen on-device package into an app-private cache that you can delete on rollback. That is a mobile packaging decision, not a server-operations guide, and it belongs in the first PR description.

// Proposed Android client: hour-one traffic talks to a revocable host.
// Do not ship this token in the APK. Inject it from CI or a local untracked file.
data class HourOneEndpoint(
    val baseUrl: String,          // development host, not production inference
    val token: String             // memory only; never log the value
)

fun shouldDownloadOnDeviceModel(contractFrozen: Boolean, prAddsPackagedWeights: Boolean): Boolean {
    return contractFrozen && prAddsPackagedWeights
}

If shouldDownloadOnDeviceModel is false, the first-hour build must not create a DownloadManager request. Reviewers should reject a PR that fetches weights “just to see if generation works” on a shared engineering phone.

Artifact: a rollback storage audit you can run in one sitting

The original artifact here is a decision table plus a pair of storage helpers. Run the table on one device after the lifecycle transition you wrote on the card. Label every cell as observed or not run; do not fill latency or battery fields you did not measure.

Decision table

First-hour action	Where the file must live	After `git revert` you should still check	Pass if
Prompt-contract trial	Remote development host only	App logs and interceptors	No weight file on device
Packaged on-device model in the PR	App-private `cacheDir` / Caches	`cache/`, uninstall leftover, backup	File gone or marked excluded
Accidental `DownloadManager` save	Never	`Download/` and MediaStore	Zero indexed model files
Backgrounded mid-download	Incomplete temp in private cache	Force-stop, then cold start	Temp deleted, no retry into Downloads
Rollback of the PR	Source tree clean	Same user profile filesystem	No orphan `.bin` / `.task` / `.tflite`

Print the table in the PR with a third column filled from adb or Finder, not from hope. A blank cell means the test was not run, which is honest and useful. A cell that claims “clean” without a path is not useful.

Android: pin weights to private cache

// Proposed helper. Treat as unexecuted sample until you run it on the device card.
fun modelCacheFile(context: Context, name: String): File {
    val dir = File(context.cacheDir, "on-device-models").apply { mkdirs() }
    require(!name.contains("..")) { "refusing path traversal in model name" }
    return File(dir, name)
}

fun assertNotShared(file: File, context: Context) {
    val downloads = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS)
    check(!file.absolutePath.startsWith(downloads.absolutePath)) {
        "first-hour model escaped into Downloads"
    }
    check(file.absolutePath.startsWith(context.cacheDir.absolutePath)) {
        "first-hour model is not in app-private cache"
    }
}

# Proposed audit after you background the app and revert the PR.
# Replace the package name with the sample you actually installed.
adb shell am force-stop com.example.voiceapp
adb shell run-as com.example.voiceapp ls -la cache/on-device-models || true
adb shell content query --uri content://media/external/file \
  --projection _display_name:_data \
  --where "_display_name LIKE '%.tflite' OR _display_name LIKE '%.bin'"

If content query prints a row, the rollback failed even when GitHub is green. Delete that row in a follow-up PR that only removes storage, and keep the original feature revert separate so bisect stays readable. Do not hide a storage cleanup inside a thirty-file refactor.

iOS: exclude caches from backup

// Proposed helper. Unexecuted until you run it on the iOS device listed on the card.
func modelCacheURL(filename: String) throws -> URL {
    let caches = FileManager.default.urls(for: .cachesDirectory, in: .userDomainMask)[0]
    let dir = caches.appendingPathComponent("on-device-models", isDirectory: true)
    try FileManager.default.createDirectory(at: dir, withIntermediateDirectories: true)
    var url = dir.appendingPathComponent(filename)
    var values = URLResourceValues()
    values.isExcludedFromBackup = true
    try url.setResourceValues(values)
    return url
}

After revert, open Files, connect Finder, and search for the model filename on that same handset. A file that appears in an unencrypted backup is a first-hour leak, even if the app UI no longer offers generation. Cross-platform wrappers in Flutter or React Native need the same rule: native cache APIs, not getApplicationDocumentsDirectory() dumped into a shareable folder.

Proposed first-hour sequence

Run this as a single-device experiment. Stop if any step needs a second phone or a production key.

Fill the device card while the app is on the first-run voice screen in the foreground.
Confirm the build has no DownloadManager enqueue and no iOS Downloads bookmark.
Exercise the prompt contract against the revocable development host, then background the app for one minute.
Force-stop the process, cold start, and confirm no model filename exists in shared storage.
Merge nothing. Revert the local branch as if the first PR was rejected.
Repeat the adb or Finder search on the same user profile.
Uninstall, reinstall the last main build, and search again for restored cache files.
Write pass or fail per table row, including rows you skipped, with the OS version beside each row.

Expected observation, if the helpers are wired: shared storage stays empty, and only an app-private cache could ever hold a packaged weight. Recovery outcome you want: after revert and uninstall, the filename is gone, not silently restored by backup. If the file reappears, the bug is backup eligibility, not the Git revert.

Limitations and who should not use this

This workflow is for a junior engineer’s first hour, first PR, and first rollback on one personal or loaner handset. It is not a thermal study, not a tokens-per-second chart, and not a claim about every Android OEM’s backup implementation. Work profiles, MDM, and shared demo kiosks need extra policy that this article does not provide.

Do not follow this approach if you are shipping a production speech feature this week and still lack a legal review of on-device artifacts. Do not use a public development host for prompts that contain user audio, medical text, or customer identifiers. Do not treat a free remote option as an offline guarantee; airplane mode still requires a packaged model and a separate radio-wake test.

Skip the remote-host path when your repository already vendors a tiny on-device model and the first PR only changes UI copy. In that case you still run the storage audit, because a previous intern’s Downloads file may already be sitting on the loaner phone. The audit is the durable part; the host is optional scaffolding.

What to send back if you run it

If you run this sequence, reply with device, OS, the exact transition, and whether the file recovered, restarted, or silently disappeared. Include the framework versions and whether backup was enabled, because those two fields change the uninstall row. Comparable evidence from one iPhone and one Pixel is worth more than a generic mobile UX thread with no paths.

Keep First-Hour Mic Buffers Out of Your Remote Debug Host

Roronoa — Mon, 21 Sep 2026 12:37:04 +0000

You sit down with a Pixel 8 on Android 15, a fresh clone, and the sample voice screen already in the foreground. A teammate wants a first PR before lunch, and the recorder is mid-utterance when you press Home. Chat suggests a remote debug host so you can watch buffers arrive during that background transition. Those buffers are raw microphone PCM, so this first-hour choice is a privacy decision, not a convenience shortcut.

This write-up is a proposed onboarding workflow for a junior joining a mobile AI repo, not a claimed lab report. Fill every version cell with values from the device in your hand. If a step is unexecuted, keep the notes labeled as a proposal rather than as measured behavior.

The failure your first hour actually creates

Junior onboarding on a mobile AI repo often starts with a mock inference URL because production keys stay locked. You need something that answers a transcribe route so the UI can move past the first recording. A public debug host looks like the fastest path when lunch is the unofficial deadline for your PR. The OS then backgrounds you, revokes the microphone, or sleeps the radio while an in-flight upload still completes.

Your first PR has now taught the sample app to treat a convenience host as a voice sink. That failure differs from backup leakage and from platform speech recognition settings that belong in a different review. This one lives in first-hour debug topology: who may receive bytes while the voice session remains open. If reviewers only check UI copy, they will miss the host that actually received the PCM.

What must stay on the device during hour one

Raw PCM or compressed microphone frames still sitting in the recorder
Partial transcripts that exist only in memory and never reached a user-visible screen
Device or install identifiers you attached as debug headers for “just this session”
Staging or production inference base URLs copied from an internal wiki into a local extra

If any of those four leave the phone for a convenience host, you do not have a debug setup. You have an accidental data path that your rollback must close before anyone else clones the branch. Treat the first-hour host as part of the threat model, not as furniture around the feature.

Proposed environment, not a measured claim

Treat the table as a form you complete on hardware you control. Do not paste these examples into a ship report unless the run actually happened.

Field	Example you should replace
Device	Pixel-class or iPhone-class hardware on your desk
OS	The Android or iOS build shown in Settings
App state	Voice screen foregrounded, one utterance in flight
Framework	React Native, Flutter, or native, versions from the lockfile
Network	Wi-Fi only, cellular disabled before you tap Record
Permission	Microphone granted, then revoked while the process is alive
Power	Unplugged; leave Battery Saver off unless that is the case
Expected	No audio bytes on any remote host; local mock sees teardown

Record module versions from package.json, pubspec.yaml, or Gradle before you file the PR. Guessing a framework version makes the next junior unable to replay your steps. Network and permission state belong in the PR body beside the screenshots, not in a later comment.

Lifecycle experiment you can finish before the first PR

This is a proposed test. Mark observations only after the commands run on your device.

Install a local mock on loopback, never a public URL, bound to 127.0.0.1.
Point a debug-only build extra at that mock and keep the extra out of release manifests.
Grant microphone, start recording, and speak one short phrase you will not reuse in tickets.
Background the app with Home or Recents before the HTTP client reports completion.
Revoke microphone from Settings while the process is still alive, then return to the app.
Confirm whether the session recovered, restarted, or silently disappeared from the UI.
Inspect the mock access log for bodies. Any media-like payload means the test failed.
Repeat once with the radio off after the request starts, without adding a cloud fallback host.

Android: revoke the mic after you background the recorder

# Proposed commands. Replace the package name with the sample app you cloned.
adb shell cmd appops set com.example.voiceai RECORD_AUDIO ignore
adb shell pm revoke com.example.voiceai android.permission.RECORD_AUDIO
adb shell dumpsys package com.example.voiceai | grep -A2 RECORD_AUDIO
# Do not relaunch from a debug intent that skips the normal activity stack.
adb logcat -s VoiceSession:D OkHttp:D AudioRecord:E | tee first-hour-mic.txt

You should see a visible error on resume, not a silent retry against a second host. If logcat prints a baseUrl that is not loopback, stop and revert the config change before you open the PR. Leaving that URL in SharedPreferences is how a one-hour experiment becomes tomorrow’s production sink.

iOS analog, still labeled as a proposal

# Simulator-only sketch. A physical iPhone run is required for the recording indicator.
xcrun simctl privacy booted revoke microphone com.example.voiceai
xcrun simctl terminate booted com.example.voiceai

On a physical iPhone, use Settings → Privacy & Security → Microphone, then the app switcher. Confirm the orange recording indicator disappears and that no background URLSession task keeps uploading. If the indicator lingers after revoke, your session object is still holding the audio unit and the first PR is not ready.

Local mock that refuses audio bodies

Keep the mock strict and small. It should answer health checks and reject anything that looks like media, including oversized JSON.

// local-voice-mock.mjs
// Proposed first-hour stub. Do not bind this port on a public interface.
import http from "node:http";

const PORT = 8787;
const MAX_BYTES = 256;

const server = http.createServer((req, res) => {
  const chunks = [];
  req.on("data", (c) => {
    chunks.push(c);
    const n = chunks.reduce((sum, x) => sum + x.length, 0);
    if (n > MAX_BYTES) {
      req.destroy();
    }
  });
  req.on("end", () => {
    const body = Buffer.concat(chunks);
    const type = req.headers["content-type"] || "";
    const looksMedia =
      type.includes("octet-stream") ||
      type.includes("audio") ||
      body.length > MAX_BYTES;

    if (looksMedia) {
      res.writeHead(403, { "content-type": "application/json" });
      res.end(JSON.stringify({ error: "audio_forbidden_on_debug_host" }));
      console.error("REJECTED media-like body", req.method, req.url, body.length);
      return;
    }

    res.writeHead(200, { "content-type": "application/json" });
    res.end(JSON.stringify({ ok: true, path: req.url, bytes: body.length }));
  });
});

server.listen(PORT, "127.0.0.1", () => {
  console.log("local mock bound to 127.0.0.1:" + PORT);
});

node local-voice-mock.mjs
adb reverse tcp:8787 tcp:8787
# The device can now call http://127.0.0.1:8787 without crossing the USB boundary.

Wire the client so backgrounding cancels the in-flight call. A quiet retry toward another host is the bug this first hour is supposed to catch, not a resilience feature you brag about in the PR.

// Proposed React Native sketch. Confirm AppState behavior against your lockfile version.
import { AppState, type NativeEventSubscription } from "react-native";

export function attachVoiceTeardown(abort: AbortController): () => void {
  const sub: NativeEventSubscription = AppState.addEventListener(
    "change",
    (state) => {
      if (state !== "active") {
        abort.abort();
      }
    }
  );
  return () => sub.remove();
}

export async function postVoiceDebugMetadata(
  url: string,
  signal: AbortSignal
): Promise<Response> {
  if (!url.startsWith("http://127.0.0.1")) {
    throw new Error("debug voice path must stay on loopback");
  }
  return fetch(url, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({
      note: "metadata-only; pcm must remain on device",
      state: "background_or_revoke_check",
    }),
    signal,
  });
}

The JSON body is intentional for hour one. You are not proving transcription quality against a golden set in this pass. You are proving that PCM never boarded a socket whose logs you do not control, including a “temporary” remote mock.

First PR shape and the rollback you rehearse before lunch

Your first PR should change three things at most: the debug extra, the teardown listener, and a test that fails when a remote host is configured. If the diff needs a fourth production file, you have left first-hour scope and should split the work. Reviewers can reason about a loopback gate. They cannot reason about a surprise cloud fallback you added “so the demo still talks.”

PR checklist

Debug base URL is loopback-only in the sample target and compile-gated out of release.
No public host lands in a committed .env, even when your laptop already gitignores that file.
adb reverse or the iOS loopback equivalent is written in the PR body as a required setup step.
Background and microphone-revoke paths include expected UI copy, not only log snippets.
Rollback is one revert plus uninstall, not a remote flag you cannot reach after hours.

Rollback rehearsal

git revert --no-edit HEAD
# Uninstall so a debug extra cannot survive in local storage across the revert.
adb uninstall com.example.voiceai
adb install app/build/outputs/apk/debug/app-debug.apk
adb logcat -c
# Cold-start the voice screen from the launcher, then grep once.
adb logcat -d | grep -E "https?://"

After reinstall, open the voice screen once and watch for the old host. If it still appears, you stored it in SharedPreferences, UserDefaults, or an encrypted file you forgot to clear. Incomplete rollback is how a junior’s first afternoon becomes an incident for whoever merges next.

Where free model access and a free server belong

You still need to draft the mock, the abort wiring, and the PR notes without pasting production audio into a chat window. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode offers free model access and a free server option that can generate the loopback stub and host a metadata-only contract check while you wait on staging credentials.

Use that server for OpenAPI fragments, health checks, and CI jobs that never see microphone bytes. Do not point the Android or iOS client at it for live voice, even when the first-hour clock is running. If an assistant asks you to paste a failing request body, refuse and paste the status code plus headers only. If you want scaffolding, try those free models on the contract text in the repo rather than on a captured utterance.

Limitations and who should skip this

This workflow does not measure latency, energy use, or model quality, and it does not replace a privacy review. It also does not prove on-device inference; it only proves the debug path cannot become a voice sink. Teams with MDM, work profiles, or certificate pinning should follow their security group instead of a first-hour loopback stub.

Skip this approach if you already have an approved internal mock that forbids media bodies. Skip it if your app must stream audio for a regulated clinical or financial workflow with a named vendor. Skip it if you cannot run on a physical device, because simulators lie about recording indicators and about USB reverse.

Do not treat a public server as equivalent to loopback because both are labeled temporary. Temporary hosts still retain access logs after you close the laptop. Temporary juniors still open pull requests that other people will copy.

What to report if you run the steps

Reply with the device, OS build, framework versions from the lockfile, and the exact transition you used. Say whether the session recovered, restarted, or silently disappeared after microphone revoke. Include whether the mock log stayed empty of media and whether rollback required a preference wipe. Comparable environment evidence from one phone is more useful than a checklist emoji on the PR template.

Keep First-Hour Prompt Text Out of Keyboard Learning

Roronoa — Sun, 20 Sep 2026 10:42:46 +0000

You join the mobile AI repo at 9:40 and the first ticket looks almost friendly. You add a multiline prompt field so testers can type a question into the on-device assistant. The app is still in the foreground on a development phone, and you have not touched Settings yet. Then you background the app, open Messages, and the keyboard suggests the private canary sentence you typed two minutes ago.

That leak is not a model bug, and it will not show up in your unit tests. iOS Keyboard Learning and Android Autofill treat a prompt box like any other text field. Your first-hour PR can ship on-device inference and still hand the user's last utterance to the IME. Treat every procedure below as a proposed single-device experiment until you record your own outcome.

What you are actually protecting

You should treat the prompt field as sensitive even when inference never leaves the device. The OS mechanism that learns those characters sits outside your process and your unit tests. Your first PR should name the strings you refuse to feed to QuickType, Gboard, and Autofill.

Keep these out of keyboard learning on the first-hour build:

system or developer prompt templates pasted during debugging sessions
user utterances that mention health, workplace, or account identifiers
few-shot examples that still contain customer names from staging
canary phrases you will later use to prove whether a leak happened

You are not hiding model weights in this pass, and you should not pretend otherwise. You are keeping first-hour text out of keyboard learning, Autofill stores, and OEM dictionaries. Those stores survive process death, and they can surface inside Messages after a single background.

Proposed test: one device, one lifecycle transition

Label this work as a proposed test until you record device, OS, keyboard, and outcome. Do not copy another person's pass or fail and treat it as your release evidence. Open with one lifecycle transition: prompt focused, then Home gesture, then a different app. If you skip the Messages check, you will ship a green build that still leaks the canary.

Record this environment before you start:

device model and OS version, plus whether this is a simulator, emulator, or hardware
application state: cold start, prompt focused, draft not yet written to disk
keyboard vendor and Autofill provider, including Gboard, Samsung Keyboard, or stock iOS
permission state: microphone is optional here, because the leak is text-only
framework versions: UIKit/SwiftUI, AndroidX, React Native, or Flutter, with exact numbers
network and power: note them so you do not mix this failure with radio or thermal bugs

Exact steps

Install a clean build and skip restoring a keyboard backup if the OS offers one.
Focus the prompt field and type a unique canary such as ZXQ-ONDEVICE-PROMPT-9182.
Submit once so the field blurs and the IME has a chance to commit the phrase.
Background the app with the Home gesture; do not force-quit before the first check.
Open Messages or Notes and type ZXQ to see whether the canary is suggested.
On Android, open Settings and inspect Autofill plus the keyboard personalization screen.
Return to the app and confirm whether the field still shows the canary after resume.
Kill the process, relaunch, and check the field, the IME bar, and any Autofill save prompt.

Expected observations on a naive first PR

iOS may offer the canary as a QuickType prediction after a single commit
Android Autofill or Gboard may store the phrase against your application package
process death may clear your ViewModel while the IME memory still keeps the canary
reinstalling the app may not clear a cloud-backed keyboard dictionary on the same account

Recovery outcome you want

the canary never appears in another app's keyboard suggestion bar
clearing the field and killing the process leaves no local prompt draft
testers do not need a keyboard dictionary reset after every internal build

If the canary silently appears in another app, the first PR failed the privacy bar. On-device inference quality does not excuse an IME side channel on a first-hour build. Write the failed observation into the PR, including keyboard vendor and OS point release.

First-hour code you should put in the PR

Treat the snippets below as starting points you still have to execute on a real device. These flags are not a guarantee against OEM keyboards, work profiles, or accessibility services. Check the framework version in the PR body so reviewers can reproduce the same traits. If a flag is missing on your min OS, document the gap instead of commenting it out quietly.

iOS UIKit

final class PromptViewController: UIViewController {
    let promptView = UITextView()

    override func viewDidLoad() {
        super.viewDidLoad()
        promptView.autocorrectionType = .no
        promptView.spellCheckingType = .no
        promptView.smartQuotesType = .no
        promptView.smartDashesType = .no
        promptView.smartInsertDeleteType = .no
        promptView.autocapitalizationType = .none
        promptView.textContentType = .none
        if #available(iOS 17.0, *) {
            promptView.inlinePredictionType = .no
        }
        if #available(iOS 18.0, *) {
            promptView.writingToolsBehavior = .none
        }
    }
}

Read Apple's UITextInputTraits notes before you assume one property disables every learning path. Writing Tools and inline predictions are newer OS mechanisms than the classic autocorrect toggle. Gate the newer properties with availability checks so the first PR still compiles on older targets. Re-run the canary after each OS bump, because keyboard subsystems change in point releases.

SwiftUI

TextEditor(text: $prompt)
    .textInputAutocapitalization(.never)
    .autocorrectionDisabled(true)
    .textContentType(.none)
    .privacySensitive(true)

The privacySensitive modifier can hide text in system screen captures and some app switcher thumbnails. It does not replace autocorrect, text content type, or inline prediction controls on the field. Keep both layers in the first PR if your testers use TestFlight screenshots during onboarding.

Android XML and view code

<EditText
    android:id="@+id/prompt"
    android:inputType="textMultiLine|textNoSuggestions"
    android:importantForAutofill="noExcludeDescendants"
    android:importantForContentCapture="noExcludeDescendants"
    android:autofillHints=""
    android:imeOptions="flagNoPersonalizedLearning" />

promptEditText.setImportantForAutofill(
    View.IMPORTANT_FOR_AUTOFILL_NO_EXCLUDE_DESCENDANTS
)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
    promptEditText.setImportantForContentCapture(
        View.IMPORTANT_FOR_CONTENT_CAPTURE_NO_EXCLUDE_DESCENDANTS
    )
}
promptEditText.setAutofillHints(null as String?)

flagNoPersonalizedLearning is an IME option, and a vendor keyboard may ignore it completely. You need importantForAutofill and importantForContentCapture because they close two different capture channels. Empty autofill hints are not enough if the view still reports itself as important for Autofill. After the XML change, still set the same flags in code so later Compose wrappers cannot drift.

Call the Autofill APIs after setContentView so the view tree does not restore a naive default. Content capture arrived later than Autofill, so wrap it with an SDK_INT check in the first PR. Null autofill hints plus IMPORTANT_FOR_AUTOFILL_NO_EXCLUDE_DESCENDANTS is the conservative pairing for prompts. Log the sdkInt and the flag values once in debug, then delete that log before you ship.

Jetpack Compose

OutlinedTextField(
    value = prompt,
    onValueChange = { prompt = it },
    keyboardOptions = KeyboardOptions(
        autoCorrectEnabled = false,
        capitalization = KeyboardCapitalization.None,
        keyboardType = KeyboardType.Text
    )
)

Compose keyboard options do not automatically disable Autofill on every BOM version you might pin. Check the AndroidX release notes for your BOM and add Autofill semantics if the canary still appears. Keep the XML flags in mind when this field is hosted inside a hybrid View/Compose screen. Hybrid trees are a common first-PR miss when a junior only patches the Compose widget.

React Native

<TextInput
  multiline
  value={prompt}
  onChangeText={setPrompt}
  autoCorrect={false}
  autoCapitalize="none"
  spellCheck={false}
  textContentType="none"
  autoComplete="off"
  importantForAutofill="no"
/>

Confirm the React Native version in your first-hour notes, because autoComplete mapping changed across releases. textContentType none is an iOS prop, and importantForAutofill is the Android counterpart on TextInput. spellCheck false does not disable Gboard personalization by itself on every Android device. If you wrap TextInput, forward these props or the first PR will look correct and still leak.

Flutter

TextField(
  controller: promptController,
  autocorrect: false,
  enableSuggestions: false,
  enableIMEPersonalizedLearning: false,
  spellCheckConfiguration: const SpellCheckConfiguration.disabled(),
  keyboardType: TextInputType.multiline,
  textCapitalization: TextCapitalization.none,
)

enableIMEPersonalizedLearning false is the Android Flutter flag that juniors miss during onboarding. Put it on the checklist beside model packaging, because it is unrelated to inference quality. SpellCheckConfiguration.disabled stops the OS spell service from taking a second copy of the buffer. Run the canary on a physical Pixel or Samsung phone, not only on the desktop emulator keyboard.

Commands that help you prove the leak

You cannot dump another vendor's keyboard database on a stock phone without extra privileges. You can still collect evidence around your process, your view flags, and accidental log copies. If the canary appears in logcat, fix logging in the same PR as the IME flags. Keyboard learning is not the only first-hour side channel on a debug mobile AI build.

# Android: inspect Autofill around your prompt view after typing the canary
adb shell dumpsys autofill | grep -A 24 "prompt"

# Android: fail the PR if debug logging echoed the canary
adb logcat -d | grep -F "ZXQ-ONDEVICE-PROMPT-9182"

# Android: confirm the focused view after you tap the field
adb shell dumpsys window windows | grep -A 12 "mCurrentFocus"

# iOS Simulator: identify the booted device before you reset test state
xcrun simctl list devices booted

On a physical iPhone, Reset Keyboard Dictionary is the recovery control after a failed canary. Document that reset because it is destructive for the tester's other learned words and shortcuts. On Android, a keyboard app reset in Settings is similarly destructive and should be a last resort. Prefer preventing the learn step over asking testers to wipe dictionaries after every build.

Decision table for the first PR

Use this table during the first PR review, not as a substitute for the canary run. If the product needs a draft after process death, store it in the app container only. File protection and encrypted storage are a different change from IME flags, so split the diffs. Do not copy prompt flags onto a public help search box or you will harm everyday typing.

Field purpose	Disable IME learning	Disable Autofill	Keep a local draft	First-PR note
On-device user prompt	Yes	Yes	Memory only unless policy requires a draft	Default for this article
Public help search	No	Usually no	Disk cache is fine	Do not reuse prompt flags
API key or session paste	Yes	Yes	Never	Use a secure field, not a prompt
Internal few-shot editor	Yes	Yes	Encrypted app storage only	Still run the canary

If reviewers ask for a surviving draft, that is a storage ticket, not an IME ticket. Mixing those concerns is how first-hour PRs grow into unreviewable diffs. Keep the canary, the flags, and the logging redaction in one privacy-sized change. Leave model packaging and rollback rehearsal to the PRs that already own those failures.

Where a coding assistant actually helps

A junior engineer can waste the first hour hunting flag names across UIKit, Jetpack, React Native, and Flutter. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source project with free model access and a free server option you can use to generate platform wrappers from the table above. You still owe the device run, because generated flags are not evidence of keyboard behavior.

Paste your real prompt widget and ask only for the platform-specific props that match this table. Then run the canary steps on one phone and record whether the suggestion recovered, restarted, or silently appeared. Skip any generated claim about battery, quotas, or model quality, because this leak is an OS input path.

Limitations, and who should not use this

This approach does not stop a user from pasting the prompt into Messages themselves on purpose. It does not control a work profile keyboard, a Bluetooth hardware keyboard, or an accessibility service. It also does not replace screenshot policy, backup exclusion, or redaction of prompt text in crash logs. Treat IME flags as a product hygiene control, not as a compliance certification for regulated data.

You should not disable learning on every text box, because navigation search becomes slower and more error prone. You should not skip the canary test because a simulator keyboard looked clean during the first hour. You should not ship FLAG_SECURE on every screen only to hide this leak; that is a different tradeoff. Health and finance clients still need legal review beyond a TextField configuration in the onboarding PR.

Inline predictions, Writing Tools, content capture, and OEM clipboard suggestions change by OS point release. Re-run the steps when you bump minSdk or the iOS deployment target. Flutter's IME personalization flag is an Android control and will not save you on iOS. Cross-platform wrappers still need the native props on each side of the bridge.

What you should send back

Please do not reply with a generic claim that the field looked fine on your machine. Send comparable evidence: device, OS, keyboard vendor, Autofill provider, and the lifecycle transition. Include whether the canary recovered after process death, restarted after reinstall, or silently appeared elsewhere. If the canary stayed inside your process, the first PR is ready for a reviewer to reproduce.

If it escaped into the keyboard bar, fix the field before you debate on-device model quality. First-hour mobile AI work fails in OS input paths more often than it fails in the interpreter. Your onboarding checklist should include this canary beside permission revoke tests and backup exclusion checks.

Keep Your First-Hour AI Host Out of Background Resume

Roronoa — Sat, 19 Sep 2026 08:58:48 +0000

You sit down with a loaner phone, a fresh clone, and a ticket that says get inference working locally. The debug build sits in the foreground, microphone permission is already granted, and the radio is ordinary office Wi-Fi. You paste a laptop prototype host into a gitignored config because production still needs a key you lack. Then you switch apps to read the README, and that single background transition is where first-hour AI PRs start leaking hosts, prompts, and retries.

This write-up is a proposed onboarding workflow, not a lab report from one named handset. You should treat every command as homework to run on hardware you control and then record. If a step cannot be reproduced on a single phone, it does not belong in your first pull request.

Why the first hour ships the wrong host

Junior engineers joining a mobile AI repo usually fail in the same three places before lunch. The prototype URL is compiled into a flavor that QA will sideload later in the week. The prompt is printed to logcat or the Xcode console so the first completion looks debuggable. The client then retries the cloud call from onResume or scenePhase == .active, as if every foregrounding were a new chat turn.

None of those mistakes require a large model, a fancy SDK, or a production account. They appear because the first hour rewards a green spinner more than a lifecycle check. You can still point a debug build at a desk-side server. You cannot let that server become the default target after the user leaves the app.

Cross-platform wrappers make the same resume mistake with extra listeners you will not see in the activity file. Flutter plugins and React Native networking stacks can hold a JS or Dart queue that survives an Android pause. Your first PR has to name those listeners, or the gate you add in Kotlin will not be the gate that actually runs.

First-hour isolation checklist

Work through this list before you open the pull request, and paste the results into the description.

Put the prototype host in a gitignored file, never in AndroidManifest.xml, Info.plist, or a committed .env.
Gate the host with a debug-only build flag so release flavors cannot resolve it at all.
Refuse to log raw prompts, transcripts, tokens, or authorization headers at any level.
Do not enqueue inference from resume, start, or applicationDidBecomeActive.
Record microphone and network permission state before and after a revoke test.
Write the rollback command in the PR so a reviewer can revert without asking you.

Android: local host, not a shipped constant

Keep desk addresses in local.properties, which Gradle already knows how to ignore in a normal Android tree.

# local.properties — gitignored
ai.prototype.host=http://192.168.1.23:8080
ai.prototype.enabled=true

Wire those values only into the debug BuildConfig block, and force the release flavor to empty strings.

// android/app/build.gradle.kts
android {
    buildTypes {
        getByName("debug") {
            buildConfigField(
                "String",
                "AI_PROTOTYPE_HOST",
                "\"${project.findProperty("ai.prototype.host") ?: ""}\""
            )
            buildConfigField(
                "boolean",
                "AI_PROTOTYPE_ENABLED",
                "${project.findProperty("ai.prototype.enabled") ?: "false"}"
            )
        }
        getByName("release") {
            buildConfigField("String", "AI_PROTOTYPE_HOST", "\"\"")
            buildConfigField("boolean", "AI_PROTOTYPE_ENABLED", "false")
        }
    }
}

Make resume a no-op whenever the desk host is in play. Production code may refresh a session token, but it must not replay the last utterance.

class InferenceResumeGate(
    private val isPrototypeEnabled: Boolean,
    private val host: String
) {
    fun onForeground() {
        if (isPrototypeEnabled || host.isBlank()) {
            // Proposed behavior: never retry a desk host after backgrounding.
            return
        }
        // Production path may refresh a token. It must not replay the last prompt.
    }
}

iOS: xcconfig instead of a hardcoded URL

// Debug.xcconfig — do not commit a real desk IP
AI_PROTOTYPE_HOST = http:/$()/192.168.1.23:8080
AI_PROTOTYPE_ENABLED = YES

func scenePhaseDidChange(_ phase: ScenePhase) {
    guard phase == .active else { return }
    guard BuildFlags.prototypeEnabled == false else { return }
    // Proposed: skip prompt replay. Token refresh belongs in a dedicated session type.
}

A single-device test you can paste into the PR

Treat the following as a proposed experiment. Fill in your device, OS, and framework versions before you claim any result. Do not invent battery figures or assume a whole device class behaves the same way.

Environment to record

Device and OS, written as model plus version, not as "a modern Android phone"
App state at start: foreground, microphone allowed, Wi-Fi associated, charger optional
Framework and HTTP stack: native, React Native, or Flutter, plus client library version
Transition under test: app switcher or Home for thirty seconds, then resume
Second transition: Settings revoke of microphone, resume, then an attempted utterance

Exact steps

Launch the debug build and send one short prompt against the prototype host only.
Confirm that host appears in memory or gitignored config, not in the log buffer.
Background the app for thirty seconds without swiping the process out of recents.
Resume and watch whether a second HTTP call leaves the device toward the desk.
Revoke microphone permission, resume again, and try to speak a follow-up prompt.
Write down whether inference recovered, restarted from scratch, or silently disappeared.

Commands worth running

# Android: watch for the prototype host and prompt text
adb logcat -d | rg -i "192\.168\.|Authorization:|prompt|transcript"

# Android: revoke and restore microphone without reinstalling
adb shell pm revoke com.example.app android.permission.RECORD_AUDIO
adb shell pm grant com.example.app android.permission.RECORD_AUDIO

# Android: confirm resume did not quietly restart the process as a fake fix
adb shell dumpsys activity processes | rg com.example.app

# iOS (proposed): stream unified logs without printing utterance text
log stream --predicate 'subsystem CONTAINS "com.example.app"' --style compact

Expected observations, not invented numbers

After backgrounding, you should see zero new requests to the desk host.
After microphone revoke, the UI should explain the missing permission instead of retrying audio.
After restore, the session may restart, but it must not replay the previous utterance automatically.
Radio and energy claims stay qualitative here: if the radio wakes for the desk host, the resume gate failed.

If your first hour needs a desk-side model so the PR does not embed a production key, MonkeyCode offers free model access and a free server option you can aim at that gitignored host. Disclosure: This article was prepared as part of MonkeyCode's product outreach. That path stays honest only while it remains off release flavors, off resume retries, and off shared logging.

Decision table for the first PR

Condition	Ship in the first PR?	Rollback if it leaks
Gitignored debug host, resume gated	Yes, with the test notes attached	Delete local config, then clean rebuild
Host string in a committed sample	No	`git revert`, then rotate the host
Prompt or transcript in logs	No	Wipe log buffers and strip the logger
Retry on every `onResume`	No	Gate the client and attach the test above
Release flavor resolves the desk IP	No	Flip `BuildConfig` and cut a new build
Microphone missing, call still fires	No	Fail closed and show a permission screen

First PR, then the first rollback

Your first pull request should carry three artifacts besides the feature diff itself. Include the filled environment table, the log command you actually ran, and a rollback snippet a reviewer can execute without a Slack thread. Reviewers are not mind readers, and onboarding tickets die when the only recovery plan is "we will hotfix later."

# Proposed rollback for a leaked prototype host
git revert --no-edit HEAD
rg -n "192\\.168\\.|AI_PROTOTYPE_HOST|prototype.host"
adb logcat -c
# If a shared desk server saw real utterances, rotate that endpoint before the next install.

Do not treat rollback as a follow-up chore for week two. The onboarding ticket is unfinished until a second engineer can remove the host and still compile a debug flavor. If the leaked URL was reachable from more than your laptop, rotating it is part of the same PR, not a private note.

Limitations and who should skip this

This workflow does not measure milliwatts, does not name a neural net, and does not claim any cloud path will remain free. OS vendors change background rules between minor releases, and a plugin may register resume hooks your activity-level gate never sees. Emulators often skip radio, permission sheets, and thermal throttling that production phones will hit during the same thirty-second background window.

Skip this approach if you handle real user audio on day one, if legal forbids any desk-side prompt, or if you cannot run a physical device. Do not use a prototype host as a silent fallback when on-device inference fails either. That is a product decision, and it belongs in a later PR with a user-visible path, a permission story, and a rollback that QA can actually rehearse.

What to report back

If you run the resume test, comment with device, OS, and the exact transition you used. Say whether the prototype call recovered, restarted, or silently disappeared after you returned to the app. Comparable notes from one phone beat a generic claim that backgrounding already works.

Keep On-Device Transcripts Out of Phone Backup on Your First Mobile AI PR

Roronoa — Fri, 18 Sep 2026 07:01:17 +0000

You sit down with a fresh clone and a first ticket that sounds harmless on Slack. The ticket asks you to persist the last voice session so offline replay still works after the process dies. Nobody mentions backup, restore, or what happens when a reviewer asks you to roll the PR back. The trap is not the schema; it is whether that file rides into iCloud or Google backup after you merge.

This is a proposed first-hour workflow for a junior engineer joining a mobile AI repo, not a scored lab report. You will treat backup exclusion as a merge gate, then rehearse restore after rollback. Record the device, OS, framework, permission state, and network condition before you claim anything recovered, restarted, or silently disappeared.

The first-hour failure mode nobody put in the ticket

On-device voice and offline replay almost always grow a local store during the first PR. That store holds utterances, partial captions, and sometimes speaker labels that never belonged in a cloud sync channel. Phone backup is an OS mechanism, not your product sync, and it can copy those files while the app is backgrounded or even uninstalled later. If your first cache lands in Documents, shared storage, or a default database path, a restore can resurrect user speech after you thought the rollback was clean.

You should assume AI-drafted persistence will pick the convenient directory unless you constrain it. Convenient directories are the ones backup systems already know how to upload. Your job in hour one is not to debate schema elegance. Your job is to prove the transcript file is excluded, then prove a restore cannot bring it back after revert.

What you need to record before you touch files

Fill this block in the PR description before you paste commands. Do not invent numbers; leave blanks until a device actually answers you.

Device and OS: for example Pixel 8a / Android 15, or iPhone 14 / iOS 18.6
App state: fresh install, logged-out, microphone permission denied or granted
Framework: native, React Native, or Flutter, plus the exact dependency versions
Network: Wi-Fi, cellular, or airplane mode, because some backup transports wait for unmetered links
Power: charging or battery saver, because backup daemons defer work under energy pressure
Expected observation: the transcript file exists for offline replay, but it is absent from backup contents
Recovery outcome after rollback: the file is gone, and a restored backup does not recreate it

If you cannot name the OS backup transport, you are not ready to merge the cache. Write that limitation in the PR instead of calling the feature offline-ready.

A proposed backup-and-restore experiment

Label this as an unexecuted checklist until you run it on one physical device. Do not copy a lifecycle matrix from another PR and call it coverage.

Install a debug build that writes one short transcript after a single offline session.
Confirm the file path with the commands in the inspection section below.
Trigger backup with the platform tool for that OS, then inspect the backup contents or exclusion flags.
Revert the PR or uninstall the build, then restore the backup onto the same device.
Open the app cold and check whether utterances reappear without a new recording.
Grant and revoke microphone permission once, then repeat backup, because some queues rewrite the store on denial.

You are looking for three outcomes only: recovered, restarted empty, or silently disappeared. Anything else belongs in limitations, not in a pass comment.

Exclude the transcript store on iOS

Keep the SQLite file in Application Support, not in Documents, then set the exclusion flag on the file URL. Documents is user data from the system's point of view, which makes it a backup candidate even when you consider it a cache. Caches can be purged under storage pressure, so it is the wrong place for replay that must survive a cold start. Application Support plus an explicit exclusion is the usual honest compromise.

import Foundation

enum TranscriptStore {
    static func url() throws -> URL {
        let root = try FileManager.default.url(
            for: .applicationSupportDirectory,
            in: .userDomainMask,
            appropriateFor: nil,
            create: true
        )
        let dir = root.appendingPathComponent("voice-replay", isDirectory: true)
        try FileManager.default.createDirectory(at: dir, withIntermediateDirectories: true)
        return dir.appendingPathComponent("transcripts.sqlite")
    }

    static func excludeFromBackup() throws {
        var url = try url()
        var values = URLResourceValues()
        values.isExcludedFromBackup = true
        try url.setResourceValues(values)
    }
}

Call excludeFromBackup() after the first successful write, then read the flag back. A write that never sets the resource value will look fine in the simulator until someone restores a laptop backup. Proposed check: if isExcludedFromBackup is not true, fail the debug launch, not just a log line.

func assertExcludedFromBackup(_ url: URL) throws {
    let values = try url.resourceValues(forKeys: [.isExcludedFromBackupKey])
    precondition(values.isExcludedFromBackup == true, "transcript store is backup-eligible")
}

Exclude the transcript store on Android

Android Auto Backup and device-to-device migration read your manifest, not your code comments. A default android:allowBackup="true" with no exclusion rules will pack app databases when Google backup runs. Android 12 and later also honor dataExtractionRules for cloud backup versus device transfer, so you should ship both the older and newer XML. Put transcripts in internal storage, never in shared storage, and name the file so a reviewer can grep it.

<!-- AndroidManifest.xml -->
<application
    android:allowBackup="true"
    android:fullBackupContent="@xml/backup_rules"
    android:dataExtractionRules="@xml/data_extraction_rules">

<!-- res/xml/backup_rules.xml -->
<full-backup-content>
    <exclude domain="database" path="transcripts.db" />
    <exclude domain="file" path="voice-replay/" />
</full-backup-content>

<!-- res/xml/data_extraction_rules.xml -->
<data-extraction-rules>
    <cloud-backup>
        <exclude domain="database" path="transcripts.db" />
        <exclude domain="file" path="voice-replay/" />
    </cloud-backup>
    <device-transfer>
        <exclude domain="database" path="transcripts.db" />
        <exclude domain="file" path="voice-replay/" />
    </device-transfer>
</data-extraction-rules>

If the product must restore settings across phones, exclude only the utterance store, not the entire app. A blanket allowBackup="false" hides the problem from review and breaks legitimate preference migration. Call that tradeoff out in the PR so QA does not treat a missing backup as a privacy win.

Cross-platform gotchas in Flutter and React Native

Flutter's getApplicationDocumentsDirectory() maps to backup-eligible locations on both platforms more often than juniors expect. Prefer application-support or internal files, then still set the native exclusion because Dart cannot see iCloud flags by itself. React Native file helpers have the same split: a path that works offline is not automatically excluded from Auto Backup. Add a tiny native module or config plugin that sets the iOS resource value and ships the Android XML, then fail CI if those files are missing from the merged artifacts.

// Proposed Flutter check, not a measured benchmark.
final support = await getApplicationSupportDirectory();
final file = File('${support.path}/voice-replay/transcripts.sqlite');
await file.parent.create(recursive: true);
await file.writeAsBytes(bytes, flush: true);
// Call a MethodChannel that sets isExcludedFromBackup / verifies XML merge.

Do not let the first PR store transcripts beside model shards or logs. Mixed directories make exclusion rules brittle, and the next engineer will add a screenshot cache that inherits the wrong policy.

Commands you can run before the PR

These commands inspect state. They are not exploits, and they will not print a pass unless you read the output against the expected path.

iOS Simulator, proposed:

# Record the simulator OS version in the PR.
xcrun simctl list devices booted
APP_DATA=$(xcrun simctl get_app_container booted com.example.voiceapp data)
find "$APP_DATA" -name 'transcripts.sqlite'
xattr -p com.apple.MobileBackup "$APP_DATA/Library/Application Support/voice-replay/transcripts.sqlite"

A value of 1 on com.apple.MobileBackup means excluded. Missing xattr after a write means your Swift flag never stuck. Re-run after a simulated restore if your Xcode version exposes that flow; otherwise use a device and say so.

Android debug build, proposed:

adb shell getprop ro.build.version.release
adb shell dumpsys package com.example.voiceapp | grep -A4 -i backup
adb shell run-as com.example.voiceapp ls -la files/voice-replay databases
# Optional: request an immediate backup, then confirm the transport did not list transcripts.db
adb shell bmgr backupnow com.example.voiceapp

If run-as fails, you are not on a debug install and you should stop. Do not switch to world-readable storage just to make listing easier. Paste the command output into the PR so reviewers can see the path and the backup flags together.

Rollback is not uninstall

Your first rollback rehearsal should restore a backup taken while the bad cache still existed. Uninstalling the debug build only proves the package is gone, not that the OS forgot the utterances. A teammate who later restores the phone for a device swap can resurrect speech that your revert never deleted from backup storage.

Walk this sequence on one device and write the outcome in one sentence.

Merge candidate writes transcripts.sqlite or transcripts.db during an offline session.
Backup completes while the file still exists.
You revert the PR, or you install a build that no longer ships the cache code.
You restore the backup taken in step 2.
Cold start: the transcript must not reappear, and the exclusion must still apply if the file is recreated empty.

If the restored app shows the old utterance, the first PR is not rolled back in any user-visible sense. Fix exclusion, wipe the local file on version downgrade, and repeat the restore. Do not call that wipe a privacy feature unless you also proved backup no longer contains the bytes.

Drafting helpers with free model access

Disclosure: This article was prepared as part of MonkeyCode's product outreach. A junior can use MonkeyCode's free model access and free server option to draft the exclusion helper, the XML stubs, or a PR checklist from this article. That is a reasonable way to get a first patch onto the branch without waiting on a paid seat. It does not replace the device commands, and it does not prove backup exclusion by itself.

Ask the model for the resource-value call and the two Android XML files, then you run the inspection on hardware. If the draft points at Documents, shared storage, or allowBackup="false" with no explanation, reject it the same way you would reject a hand-written patch. Keep the chat log out of the PR; attach the xattr, dumpsys, and bmgr output instead.

Decision table

First-PR choice	Offline replay after kill	Likely backup behavior	Rollback after restore
Documents or default app database, no exclusion	Works	Transcripts often included	Old utterances can return
Caches directory only	May vanish under storage pressure	Sometimes skipped, not guaranteed	Replay randomly dies
Application Support or internal files, exclusion set, XML merged	Works if you re-open the store	Expected exclude if flags stick	Restore should not resurrect speech
`allowBackup="false"` for the whole app	Works	Settings and honest data also skipped	Hides the review signal

Use the third row unless product, legal, or accessibility requires cross-device transcript restore. If you do require restore, encrypt at rest, document the transport, and stop calling the feature on-device-only.

Limitations, and who should not ship this

This workflow does not measure backup bytes, radio wake, or battery drain, and you should not invent those figures. Exclusion flags can lag across OS versions, work profiles, and manufacturer backup apps that ignore Google’s XML. Simulator xattr checks are weaker than a device restore, and bmgr output varies by Play services and the selected transport. Cross-platform plugins may generate a second database file whose name never appears in your rules.

Do not follow this exclusion path if your product must legally retain conversation history across device replacement. Do not use it as a substitute for server-side deletion, because a file that never entered backup can still live in crash dumps or screenshots. Security reviewers, not the on-call junior, should decide whether device-to-device transfer is allowed for any remaining metadata.

If you run this on one phone, post the device, OS, the exact transition, and whether the transcript recovered, restarted empty, or silently disappeared. Comparable environment evidence is the only thing that makes the next junior’s first PR safer than yours.

Keep Cloud Fallback Out of Radio Wake After Airplane Mode

Roronoa — Thu, 17 Sep 2026 05:11:32 +0000

You sit with a Pixel on Android 14 or an iPhone on iOS 18, sample chat already installed. The screen is foregrounded, Wi-Fi is associated, and Battery Saver is still off for this first pass. You submit a short prompt, then enable airplane mode before any token reaches the bubble. That single transition tells you whether onboarding shipped an offline contract or only a cafeteria Wi-Fi demo.

Hybrid chat usually fails this first-hour check

Hybrid samples keep an on-device engine for the common prompt and a cloud client for everything else. The cloud client usually lives behind a retry interceptor, a flavor URL, or a latency flag that panics too early. Airplane mode should make that URL unusable, but interceptors still open DNS and can wake cellular when the mode lifts. Your first PR should freeze that client whenever the OS path reports no validated network.

This is not a model-quality argument and not a placement essay about phones versus regional GPUs. It is a junior onboarding contract: the first hour, the first pull request, and the first rollback of the fallback host. If the typing indicator hangs, then suddenly talks to the network after radios return, the demo you saw on Wi-Fi was not engineering yet.

Record these facts before you touch product code

Write the environment into the PR description so a reviewer can replay the same transition.

Device marketing name, SoC if you know it, and the exact OS build string
App stack and versions: native, React Native, or Flutter, plus the HTTP client library
Starting network: office Wi-Fi, cellular only, or already offline
Permission state for microphone, local network, and background refresh, even if unused
Power state: charging, Battery Saver / Low Power Mode, or neither
The lifecycle step: airplane mode during an in-flight prompt, not after the bubble finishes

Do not treat an emulator airplane toggle as the same experiment as a physical radio. Emulators often fake connectivity without the DNS, interface, and wakeup behavior you will see on hardware.

Inventory the checkout in the first hour

You should grep the repository before rewriting prompts, because fallback hostnames hide in more places than .env.example. Run this from the app root and paste the hits you actually intend to gate.

# Record matching paths in the PR. Do not commit secrets you uncover.
rg -n -i "https?://|inference|fallback|baseUrl|BASE_URL|generativelanguage" \
  --glob '!**/node_modules/**' --glob '!**/Pods/**' --glob '!**/.git/**'

rg -n -i "OkHttp|NSURLSession|Alamofire|Dio|chopper|ConnectivityManager|NWPathMonitor" \
  --glob '!**/node_modules/**'

Then write a three-line inventory a teammate can challenge.

On-device engine and the packaged asset or module that actually loads it.
Cloud fallback class and the hostname it resolves in this flavor.
Build flag that must prevent constructing that client when the path is unvalidated.

If you cannot name those three things after the first hour, you are not ready to claim offline support in the pull request.

Proposed airplane-mode experiment

This is a proposed single-device experiment, not a lab result with invented first-token times. Copy the steps, fill in your versions, and report whether the UI recovered, restarted, or silently disappeared.

Preconditions you should not skip

You need a physical device, a flavor that still contains the on-device model, and a build that still compiles the cloud client. Keep Battery Saver off for pass A so power policy is not the hidden variable. Skip VPN profiles for this hour, because leftover tunnels make airplane mode look satisfied.

Steps

Launch the chat screen and confirm the composer is focused in the foreground session.
Confirm Battery Saver or Low Power Mode is off so pass A has a clean power baseline.
Send a prompt the on-device path should handle without tools, browsing, or extra host calls.
Enable airplane mode within one second so Wi-Fi and cellular drop during the in-flight request.
Wait thirty seconds without tapping timeouts, unlocking dialogs, or backgrounding the app.
Note a local answer, a closed offline string, or a spinner that never resolves into UI.
Repeat pass B with Battery Saver or Low Power Mode already enabled before you submit.
Repeat pass C by enabling airplane mode first, then sending a cold prompt with radios down.

Contract you can assert without fake benchmarks

Pass A answers on-device or fails closed with offline copy, never with a hostname error string.
Pass A leaves no DNS lookup and no TLS handshake in logcat or Console after the airplane toggle.
Pass B may stretch token time under Low Power Mode, but it must not flip the flag toward cloud.
Pass C must not enqueue a retry that fires later when the user disables airplane mode.
Restoring radios without a resubmit must not replay the prompt against the fallback host.

If a retry fires when radios return, the first PR is incomplete even when the Wi-Fi demo looked polished.

# Android: capture after pass A, before you disable airplane mode.
adb logcat -d | rg -i "okhttp|dns|tls handshake|fallback|Unable to resolve host"

On iOS, filter Console for your bundle identifier during the same window and look for nw_connection or NSURLSession work that starts after the toggle. Any new connection there is a failed gate, not a flaky staging anecdote.

Artifact: refuse cloud work before DNS starts

Keep the gate beside the HTTP client, not inside a prompt formatter that still constructs the call. The operating system already knows whether a validated path exists. Ask it before you allocate OkHttp, URLSession, or Dio.

Android gate (proposed Kotlin)

class InferencePathGate(
    private val connectivity: ConnectivityManager
) {
    fun allowCloudFallback(): Boolean {
        val network = connectivity.activeNetwork ?: return false
        val caps = connectivity.getNetworkCapabilities(network) ?: return false
        val hasTransport =
            caps.hasTransport(NetworkCapabilities.TRANSPORT_WIFI) ||
            caps.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR) ||
            caps.hasTransport(NetworkCapabilities.TRANSPORT_ETHERNET)
        val hasInternet =
            caps.hasCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET) &&
            caps.hasCapability(NetworkCapabilities.NET_CAPABILITY_VALIDATED)
        return hasTransport && hasInternet
    }
}

class AirplaneSafeInterceptor(
    private val gate: InferencePathGate
) : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        if (!gate.allowCloudFallback()) {
            throw IOException("cloud fallback blocked: no validated path")
        }
        return chain.proceed(chain.request())
    }
}

Call allowCloudFallback() on the same path you would have opened the client. Throwing before chain.proceed is the point: you never give the interceptor a chance to resolve a name.

iOS gate (proposed Swift)

import Network

final class InferencePathGate {
    private let monitor = NWPathMonitor()
    private let queue = DispatchQueue(label: "inference.path.gate")
    private var path: NWPath?

    func start() {
        monitor.pathUpdateHandler = { [weak self] newPath in
            self?.path = newPath
        }
        monitor.start(queue: queue)
    }

    func allowCloudFallback() -> Bool {
        guard let path, path.status == .satisfied else { return false }
        return path.usesInterfaceType(.wifi) ||
            path.usesInterfaceType(.cellular) ||
            path.usesInterfaceType(.wiredEthernet)
    }
}

Do not treat path.status == .satisfied as permission to talk to the public internet. Airplane mode with a leftover VPN or local interface can still look satisfied until you check the transport you actually intended.

Cross-platform juniors: native gate, thin bridge

If you joined a React Native or Flutter repo, still implement the gate in native code for this first PR. JavaScript reachability plugins often lag the radio by about a second, which is enough for a retry interceptor to start work you cannot see in the JS console.

// Proposed only. Do not treat this plugin as the final airplane-mode gate.
import 'package:connectivity_plus/connectivity_plus.dart';

Future<bool> allowCloudFallbackJsLayer() async {
  final results = await Connectivity().checkConnectivity();
  if (results.contains(ConnectivityResult.none)) return false;
  return results.contains(ConnectivityResult.wifi) ||
      results.contains(ConnectivityResult.mobile) ||
      results.contains(ConnectivityResult.ethernet);
}

Expose one method, allowCloudFallback(): Boolean, and refuse to import or construct the cloud SDK when it is false. The first PR can be that bridge plus the three airplane-mode passes, without a prompt rewrite.

First PR, then the first rollback of the host

Your pull request should carry the inventory, the three passes, and a rollback a teammate can run after you leave Slack. Rollback is not “delete the on-device model.” Rollback is “stop constructing the fallback client, then destroy the hostname you used while proving the gate.”

Work the rehearsal in this order so you do not debug against shared staging.

Flip the flavor flag so the fallback client is never constructed in that build.
Re-run pass C and confirm you still answer locally or fail closed with offline copy.
Restore the flag and point FALLBACK_BASE_URL at a throwaway host you control.
Re-run airplane mode and confirm that host’s access log stays empty, then delete the host.

# Uncommitted local flavor. Do not paste real tokens into the PR.
FALLBACK_ENABLED=true
FALLBACK_BASE_URL=https://your-throwaway-host.example

A junior engineer should not prove this gate against the team’s long-lived staging inference box. That hostname shows up in other people’s captures, and it trains you to ignore airplane-mode failures because “staging was flaky today.”

When you need a personal fallback URL for step 3, a short-lived server is enough. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode offers free model access and a free server option you can use as that throwaway host, then discard after the rollback rehearsal. Keep the URL out of the default flavor once the path gate is proven.

Decision table to paste under the PR test plan

Condition	Cloud client	On-device engine	Radio / DNS	User-visible result
Wi-Fi, charging, foreground	allowed only if local engine declines	first choice	normal	answer or explicit local fail
Airplane during in-flight prompt	must not start	continue or cancel locally	no new DNS	answer, offline copy, or cancelled
Airplane before a cold prompt	must not start	run or fail closed	no new DNS	no spinner that later hits cloud
Low Power Mode plus airplane	must not start	may be slower	no radio wake	same contract, different latency
Radios return without resubmit	must not flush a queue	idle	no surprise TLS	wait for the user

If any row depends on “the interceptor will 500 anyway,” the gate is not done. Fail closed in the UI instead of waiting for a host error that also proves you woke the radio.

Limitations and who should skip this

This workflow does not measure model quality, tokens per second, or thermal headroom on a given SoC. It also does not replace a privacy review of logcat, bugreports, screenshots, or backup artifacts. Skip it if your app has no on-device path and honestly requires the network for every token. Skip it if you only have an emulator, because you cannot observe radio wake there with confidence. Skip it if a legal or safety flow must reach a server even while offline; that flow needs an explicit online requirement, not a silent fallback.

Do not copy latency numbers from another phone into your onboarding PR. Different compile caches, thermal states, and NNAPI or Core ML backends will move first-token time without changing the airplane-mode contract you are actually shipping.

Ask for comparable evidence, not vibes

Leave the device name, OS build, and the exact transition you ran: airplane during in-flight, airplane then cold prompt, or Low Power Mode combined. Say whether the UI recovered with a local answer, restarted the request, or silently disappeared when radios returned. If cloud traffic still appeared, name the class that opened the socket so the next junior can grep it in the first hour.

Keep Platform Speech Recognition On-Device on Your First Mobile AI PR

Roronoa — Wed, 16 Sep 2026 03:31:41 +0000

You join the mobile AI squad on Tuesday with a Pixel 8a running Android 15 and a debug APK already installed. The dictation screen sits in the foreground with RECORD_AUDIO granted and SpeechRecognizer already listening. Nobody set the on-device recognizer extra, and a teammate still calls the platform API a local feature. You revoke microphone access from Settings, return without force-stopping, and watch for a leftover network socket.

That permission transition is the real first hour on this squad, not a demo after standup. You should not polish a stakeholder transcript before the recognizer is proven to stay local. Prove that speech cannot leave the device after a revoke, and that you can roll the flag back. A prior commit may already have opened the vendor cloud path without anyone noticing in review.

Treat the platform recognizer as a network API until proven otherwise

Android SpeechRecognizer and iOS SFSpeechRecognizer look on-device because the UI never leaves your activity. Both APIs can ship audio to a vendor cloud unless you opt into the on-device recognizer. Your first PR should make that opt-in explicit, testable, and reversible rather than burying it in a helper. Reviewers should reject the change without guessing which constructor the production binary actually calls.

A permission revoke does not always cancel work that already started on a background thread. Partial results, pending listeners, and cached PCM can outlive the Settings toggle by several seconds. You need a lifecycle experiment on hardware, not another prompt change in the dictation copy. Treat every "it is local by default" comment in Slack as unverified until a capture says so.

What on-device has to mean in the PR description

Write the PR so a reviewer can reject it without guessing:

The production recognizer is created with the on-device constructor or the on-device request flag.
If the device has no on-device model, the UI fails closed and never opens a network recognizer.
A microphone revoke stops listening, drops in-memory PCM, and does not start cloud work.
A feature flag can restore a disabled state in one release if the on-device pack is missing.

Those four bullets are the golden behavior for this merge. Anything else is a story about accuracy in a quiet room.

A proposed single-device experiment, not a benchmark

Do not publish latency numbers from this walkthrough because it is only a pass or fail check. Record the device, OS build, application state, and the exact Settings transition beside every note. Label the whole protocol as proposed until you have those fields filled on a physical phone. A missing speech pack is a valid outcome, and you should write it down before blaming the code.

Suggested environment

Device: one physical phone you can revoke permissions on, not an emulator image.
OS: Android 12+ so createOnDeviceSpeechRecognizer() exists, or iOS 17+ with on-device speech.
App state: foreground dictation activity, process warm, screen on, charger connected.
Network: Wi-Fi attached so a mistaken cloud path would have a route.
Permission: RECORD_AUDIO or Microphone granted at start, then revoked from system Settings.
Power: stay off battery saver so the OS does not silently throttle listeners.

Emulators often fake speech services and will lie about on-device availability. Skip them for this PR, even when the Dart or Kotlin unit tests already pass on CI.

Exact steps

Install a debug build whose application ID matches the one you will inspect with adb or Console.
Confirm the on-device speech pack is installed, or write down that it is missing before you start.
Open the dictation screen and start listening with a phrase you chose in advance.
Leave the process running, switch to Settings, and revoke microphone access for the app.
Return to the dictation screen without force-stopping, and wait thirty seconds.
Capture logs, a proxy session, and the UI state, then decide whether audio recovered, restarted, or vanished.

Expected observations if the PR is honest

Write the expected result before you touch Settings, then compare it with the capture. After revoke, listening should stop and the UI should show a permission error, not a spinner. The proxy should record no new TLS client hello to speech endpoints during those thirty seconds. Log lines should not print the audio sample, the partial transcript, or a cloud hostname.

If the buffer silently disappears with no error, that is still a defect for reviewers. The reviewer cannot tell a clean cancel from a swallowed upload without an explicit permission error. Killing and restarting the app must not replay the pre-revoke buffer either. Silent success is how leaked audio hides in a first-week merge.

Guard the Android constructor before you touch UI copy

The platform gives you two constructors, and the older factory is the network-friendly default path. Your first PR should call the on-device factory and refuse to fall back to the legacy one. Fail closed when the speech pack is missing, even if that makes the dictation button show an error. Do not hide a cloud recognizer behind a catch block that "keeps the feature working" on older phones.

// Proposed production path. Confirm on a physical device before you merge.
fun buildRecognizer(context: Context): SpeechRecognizer {
    if (!SpeechRecognizer.isOnDeviceRecognitionAvailable(context)) {
        error("on-device speech pack missing; fail closed")
    }
    return SpeechRecognizer.createOnDeviceSpeechRecognizer(context)
}

fun buildIntent(locale: Locale): Intent {
    return Intent(RecognizerIntent.ACTION_RECOGNIZE_SPEECH).apply {
        putExtra(RecognizerIntent.EXTRA_LANGUAGE, locale.toLanguageTag())
        putExtra(RecognizerIntent.EXTRA_PREFER_OFFLINE, true)
        putExtra(RecognizerIntent.EXTRA_PARTIAL_RESULTS, true)
    }
}

fun onPermissionRevoked(recognizer: SpeechRecognizer?, buffer: ByteArray?) {
    recognizer?.cancel()
    recognizer?.destroy()
    buffer?.fill(0)
}

Wire the revoke path to onStop and to a permission check when the activity resumes from Settings. Do not wait for a future onError from the recognizer, because that callback can arrive late. A late onError often means a network retry already started on a thread you do not control. Clear the PCM buffer in the same function that destroys the recognizer so logs cannot dump it later.

# Proposed checks for your first PR, run on the local debug APK.
unzip -p app-debug.apk classes*.dex | strings | grep -c createSpeechRecognizer
unzip -p app-debug.apk classes*.dex | strings | grep -c createOnDeviceSpeechRecognizer
adb shell dumpsys package com.example.dictation | grep RECORD_AUDIO
adb shell appops get com.example.dictation RECORD_AUDIO
adb logcat -s SpeechRecognizer:* ActivityManager:* | tee first-hour-speech.log

You want the default factory count at zero in release dex, and the on-device factory present. App ops should read deny after the Settings revoke, and the UI should match that denied state. If strings still contain a speech hostname, treat the PR as failed even when the UI looks correct. Run the same grep on the AAB you plan to ship, not only on the local debug APK.

Guard the iOS request flag the same morning

SFSpeechRecognizer can still hop to Apple servers when requiresOnDeviceRecognition stays false on the request. Set the flag first, then fail closed if the locale cannot run recognition on the device. Do not keep a second SFSpeechRecognitionRequest around for "when the user is on Wi-Fi." A Wi-Fi-only fallback is still a cloud path, and it will surprise you during the revoke test.

// Proposed production path. Confirm on a physical iPhone before you merge.
func makeRequest(locale: Locale) throws -> SFSpeechAudioBufferRecognitionRequest {
    let recognizer = SFSpeechRecognizer(locale: locale)
    guard let recognizer, recognizer.supportsOnDeviceRecognition else {
        throw SpeechGuardError.onDeviceModelMissing
    }
    let request = SFSpeechAudioBufferRecognitionRequest()
    request.requiresOnDeviceRecognition = true
    request.shouldReportPartialResults = true
    request.taskHint = .dictation
    return request
}

func dropSession(engine: AVAudioEngine, buffer: AVAudioPCMBuffer?) {
    engine.stop()
    engine.inputNode.removeTap(onBus: 0)
    if let channel = buffer?.floatChannelData?.pointee {
        channel.update(repeating: 0, count: Int(buffer!.frameLength))
    }
}

# Proposed Console filter while you revoke Microphone in Settings.
log stream --predicate 'subsystem CONTAINS "Speech"' --level debug

Juniors often dump debug WAV files into Documents during the first hour of pairing on a loaner phone. That directory can leave the device through a routine iCloud backup you will not see in Charles. Mark every debug recording excluded from backup, or write it only to a cache you delete on revoke. Never commit those WAV files to the repository, even when they contain only your own voice.

try FileManager.default.setAttributes(
    [URLResourceKey.isExcludedFromBackupKey: true],
    ofItemAtPath: debugWav.path
)

Keep eval phrases off the user's microphone

You still need a tiny golden set so reviewers can exercise the recognizer without recording coworkers. Draft twenty short phrases in the target locale, then speak them on the device at a known volume. Do not upload those recordings to a shared Drive folder, and do not commit WAV files into git. Keep the phrase list in the PR description as text, not as binary fixtures on a public fork.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. If you want a second pair of eyes while drafting that phrase list, MonkeyCode's free model access can help. Use the free server option on the eval laptop so the host never lives inside the mobile binary. Keep that hostname out of APK strings, out of plist files, and out of any runtime fallback URL. The phone's only job is on-device recognition plus a fail-closed error when the pack is missing.

Rollback if a prior commit already opened the network path

Rehearse rollback in the same PR, because on-device packs are missing on some retail SKUs. Ship a remote flag that chooses the constructor, defaulting to on-device, with a one-release kill switch. If you already shipped a network recognizer, do not fix forward by adding a second constructor. Cut a patch that forces disabled, wait until proxy traffic goes quiet, then ship the on-device flag.

Flag value	Constructor	When to use	Risk if stuck
`on_device`	`createOnDeviceSpeechRecognizer` / `requiresOnDeviceRecognition = true`	Default after this PR	Some devices show "model missing"
`disabled`	No recognizer created	Emergency rollback	Feature disappears, no audio leaves
`legacy_network`	Do not ship this value	Not for production	Audio can leave the device

If you already shipped legacy_network, record the store version that still contained the network constructor. Support needs that version number so they can tell users to update before the next privacy review. Do not leave both constructors in the binary behind an undocumented debug extra on the intent. Undocumented extras are how the default factory sneaks back in during a "temporary" support build.

Limitations, and who should not merge this as-is

This walkthrough does not claim packet captures, battery figures, or word-error rates from a device class. On-device packs vary by locale, OEM image, and whether the user downloaded a speech language model. Zeroing a PCM buffer does not erase copies already sitting in logd, a vendor HAL, or accessibility. Treat accessibility services and OEM voice assistants as separate trust boundaries you cannot control from app code.

Do not use this approach if you legally operate cloud STT with a consent screen and a DPA. Do not use it if you only have emulators, because they will not load the same speech packs. Flutter and React Native plugins often call the default Android constructor even when Dart says offline. Read the plugin source for createSpeechRecognizer before you trust a boolean named onDevice in Dart.

Tell the channel what you actually saw

Reply with the device model, OS build, and whether the on-device speech pack was actually installed. Include the exact Settings transition, and say whether you returned to the app without force-stopping. Say whether listening recovered, restarted after an error, or silently disappeared from the dictation UI. That field report is more useful to the next junior than another accuracy screenshot from a quiet office.

Your First On-Device AI PR: Ship a Golden Set and Rehearse the Rollback

Roronoa — Tue, 15 Sep 2026 03:08:49 +0000

It is 9:40 on a Tuesday, and a junior engineer on your team has just cloned the notes app repository onto a laptop with 8 GB of RAM and no GPU. The ticket says: add a summary to the note detail screen, and make it work on the phone rather than round-tripping every keystroke to a server. She writes a first version, backgrounds the app mid-inference to answer a message, and comes back to a spinner that never resolves. That single lifecycle transition — backgrounding during inference — is what her first pull request has to survive, and it is the thing most onboarding checklists leave out.

This article is a proposed test plan, not a measured benchmark. I have not run the numbers below on your hardware, and the code samples are illustrative rather than copy-paste production code. What you get instead is a repeatable structure: one golden set, one decision table, and one rollback rehearsal you can finish in your first hour.

Record the environment before you write product code

You cannot debug an inference path if you do not know what you ran it on. Open a scratch file and fill in every row below before the first commit, then paste the same table into the PR description.

Field	Fill in
Device	model and, if you have one, the exact variant
OS	version and build number, not just "Android" or "iOS"
App	version, git SHA, and build type
Framework	runtime version plus every AI-related dependency pin
Permissions	microphone, network, storage — granted or revoked at test time
Network	Wi-Fi, cellular, throttled, or airplane mode
Power	battery percentage and whether the device was charging
Transition	the one lifecycle event the ticket is really about

Notice the last row. Pick exactly one transition for your first PR. Backgrounding during inference is a good default because it is cheap to reproduce and it exposes timeout handling immediately.

Three gates your first PR has to pass

A junior engineer's first inference PR is not judged on model quality. It is judged on whether a reviewer can answer three questions without opening the app.

With network present, does the request return a valid, schema-checked result?
With network absent, permission revoked, or the endpoint returning 5xx, does the feature fall back to something deterministic instead of a spinner?
Can the feature be turned off from a configuration endpoint without shipping a new build?

If you can only prove one of the three, prove the third. A kill switch is what lets the rest of the team merge your work without betting the release on it.

Where a free endpoint fits, and what you should not assume

Gates 1 and 3 both need a small endpoint you control: something to run the golden set against, and something to serve the feature flag. MonkeyCode is an open-source project whose operator states that it offers free model access, currently described as a 10M-token free allowance, together with a free server option. Treat both as vendor claims: sign in, read the current terms, and confirm the limits in your own account before you build a habit on top of them. Token allowances, available models, and server terms can change, and this article does not assert any specific model name, hardware spec, or performance number.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Use the free model access for the golden-set runner and the free server for the flag endpoint and, if you like, a scheduled re-run of the same runner. Do not use it as the only path your app can take — see the rollback section below.

Build a 12-case golden set before you tune a prompt

Twelve cases is enough to catch schema drift and empty-output bugs, and small enough that a junior engineer can read every line in review. Store it as JSONL so the runner and any future harness can consume the same file.

{"id":"short-note","input":"Groceries: milk, eggs, bread.","max_chars":120,"must_be_single_paragraph":true}
{"id":"unicode-emoji","input":"Ideas 🎧 for the commute, plus a reminder to buy 🥛.","max_chars":120,"must_be_single_paragraph":true}
{"id":"empty-note","input":"","max_chars":120,"expect_fallback":true}
{"id":"very-long","input":"<paste 3000 characters of real notes from your own device>","max_chars":120,"must_be_single_paragraph":true}
{"id":"permission-revoked","input":"Summarize this with the microphone permission denied.","expect_fallback":true}
{"id":"offline","input":"Summarize this with radio off.","expect_fallback":true}

The important rows are the boring ones: empty input, revoked permission, and offline. Those are the states where a demo-grade implementation quietly returns null and the UI decides to show a spinner forever.

Run the golden set from a small server

The runner below is an unexecuted example. Set the base URL and key from your own project dashboard rather than hard-coding anything, and keep the API key in the server environment, never in the app bundle.

#!/usr/bin/env bash
set -euo pipefail

: "${MONKEYCODE_BASE_URL:?set from your project dashboard}"
: "${MONKEYCODE_API_KEY:?set this in the server environment}"
MODEL="${MODEL:?pick a model from your dashboard}"
OUT="golden-report.tsv"

printf 'id\tstatus\thttp\tttfb_ms\tschema_ok\tchars\n' > "$OUT"

while IFS= read -r line; do
  id=$(jq -r .id <<<"$line")
  prompt=$(jq -r .input <<<"$line")

  start=$(date +%s%3N)
  http=$(curl -sS -o /tmp/body.json -w '%{http_code}' \
    -X POST "$MONKEYCODE_BASE_URL/chat/completions" \
    -H "Authorization: Bearer $MONKEYCODE_API_KEY" \
    -H 'Content-Type: application/json' \
    -d "$(jq -nc --arg m "$MODEL" --arg p "$prompt" \
      '{model:$m,messages:[{role:"user",content:$p}],max_tokens:160,temperature:0}')")
  ttfb=$(( $(date +%s%3N) - start ))

  text=$(jq -r '.choices[0].message.content // empty' /tmp/body.json)
  chars=${#text}
  schema_ok=false
  if [ -n "$text" ] && [ "$(grep -c $'\n' <<<"$text")" -eq 0 ]; then schema_ok=true; fi

  printf '%s\t%s\t%s\t%s\t%s\t%s\n' \
    "$id" "$([ "$http" = 200 ] && echo ok || echo fail)" "$http" "$ttfb" "$schema_ok" "$chars" >> "$OUT"
done < golden_set.jsonl

column -t "$OUT"

Run it once, paste the table into the PR, and commit the script next to the app code so the next new hire inherits it. Two rules matter more than the code: keep temperature at 0 so diffs are readable, and record the wall-clock time of the run so a reviewer knows which endpoint revision produced it.

Pad the decision table with your own constraints

Before you defend a placement decision in review, write down what you actually need. The table below is a structure, not a recommendation.

Option	Latency you can promise	Offline behavior	Data egress	Rollback cost
Fully on-device	depends on your model size and device class	works	none	app release
Hosted endpoint	network round trip plus queueing	fallback needed	note text leaves the device	flag flip
Hybrid, flag-gated	hosted when healthy, local otherwise	degraded but deterministic	conditional	flag flip plus cache

Fill the latency column with measurements from your own device, not with numbers copied from someone else's blog post. If you cannot measure it, say so in the PR instead of guessing.

Rehearse the rollback in the first hour, not the first incident

A kill switch you have never exercised is a comment, not a control. Rehearse it once, in this order:

Enable the flag in your config endpoint and confirm the remote path is used.
Disable the flag, force-stop the app, and relaunch. The local fallback should appear with no crash and no empty state.
Disable the flag while the app is in the foreground and trigger a summary. Your code must read the flag per call, not once at startup.
Point the app at an unreachable endpoint and repeat step 3 to prove the timeout path, not just the flag path.
Enable airplane mode, then revoke the microphone permission, and repeat step 3 for each state.
Restore everything, and confirm the remote path returns without a reinstall.

Cache the last known flag value locally. If the config endpoint itself is down, an app that depends on a live fetch to decide whether to crash or fall back has simply moved the outage.

// Illustrative, not compiled. Gate the remote call on the cached flag
// and on a network check, and always keep the local path available.
class SummarizeNoteUseCase(
    private val flags: FeatureFlags,   // cached, refreshed in background
    private val remote: RemoteSummarizer,
    private val local: ExtractiveSummarizer,
) {
    suspend fun summarize(note: Note): Summary {
        if (!flags.noteSummaryEnabled || !remote.isReachable()) {
            return local.summarize(note)
        }
        return runCatching { remote.summarize(note) }
            .getOrElse { local.summarize(note) }
    }
}

Set your request timeout below the point where a user typically leaves the screen, and measure that interval on your own device rather than assuming it.

What goes in the PR description

Keep it short and evidence-shaped:

The environment table from the top of this article.
The golden-set report, including the offline and permission-revoked rows.
Which lifecycle transition you tested, and what the app did after it.
The rollback steps you ran, and whether the feature recovered, restarted, or silently disappeared.
What you did not test, stated plainly.

Limitations and who should not copy this

This workflow is a starting point, and it has edges worth naming out loud. It will not tell you anything about model quality on long or adversarial inputs, because twelve cases cannot. It produces no battery or thermal numbers unless you add a measurement step and a consistent power state. It assumes you have some form of remote configuration; if your app has none, build the local fallback first and treat the flag as a later addition. And if your notes contain regulated data, a hosted endpoint is a compliance decision that a golden set cannot make for you.

Skip the hosted path entirely if your product needs deterministic sub-second behavior with no network dependency, if you cannot measure latency on a real device, or if you have no way to serve a flag. A local-only extractive summary is a perfectly respectable first PR.

Send me the environment, not the opinion

If you try this on your own repo, I am more interested in your setup than in your verdict. Post the device, OS version, the transition you tested, and whether the feature recovered, restarted, or silently disappeared after it. Those four fields are what turn an onboarding story into something the next junior engineer can reproduce.

If you need a model endpoint and a small server to run the golden set while you onboard, MonkeyCode's free model access and free server option is one place to start — check the current terms in your own account first, and keep the fallback path working regardless of what the free tier looks like next month.

Keep First-Hour Inference Hosts Out of Android Bugreports

Roronoa — Sun, 13 Sep 2026 19:19:45 +0000

You sit with a Pixel 8 running Android 15, a React Native debug build, and a live voice eval still on screen. The first completion hangs, so you press Home, background the activity, and wait for the socket to die. A teammate asks for a bugreport zip, and you capture one because that feels like a normal first-hour debug move. That archive now holds the staging inference host you pointed at during onboarding, including paths you never meant to share.

Junior engineers hit this during the first hour more often than architecture reviews admit. You need a remote completion path because the on-device package is still gated behind another pull request. A debug host feels disposable until Android writes it into logcat, connectivity dumps, and crash breadcrumbs. The rest of this article is a proposed leak test, not a published benchmark with invented timings.

Why a first-hour host shows up in the zip

A debug inference URL is not only a Kotlin constant sitting in BuildConfig. OkHttp, Flipper, React Native networking, and your retry wrapper all echo that host when a stream stalls. Backgrounding a hung voice call is enough for the system to snapshot sockets, and adb bugreport keeps those lines. You also persist values that were supposed to live for a single morning.

SharedPreferences, MMKV, and AsyncStorage survive the session you treated as ephemeral. The first rollback then deletes the constant while the cached host remains on disk. Reviewers who only read the diff will miss that leftover. Treat the zip as part of the PR evidence, not as a side channel you share casually.

What you should treat as sensitive

The staging inference base URL and any path prefix that names the model route
Temporary session ids that bind a microphone buffer to that host
Debug bearer tokens pasted for hour one (never write these to logcat)
The product flavor that still compiles the remote fallback

Do not treat the host as harmless because it is not production. Bugreports leave the building when you file a ticket or drop a zip into chat. Play pre-launch reports and teammate laptops are also outside your debug device.

Proposed lab, not a measured claim

Record the environment before you change code. The setup below is a single-device experiment you can reproduce, not a claim that these exact builds were already timed.

Device: Pixel 8, or another Android 14+ phone you physically hold
OS: Android 15, developer options on, USB debugging authorized
App: React Native debug APK, microphone granted, unmetered Wi-Fi
Power: plugged in, battery optimization left at the package default
State: voice eval foregrounded, then Home to background the activity
Transition: hung completion → background → adb bugreport

Expected observation: the staging host appears under logcat or dumpsys inside bugreport-*.zip. The recovery outcome you want is stricter. After the flavor gate and the first rollback, a clean install plus a new bugreport must not contain that host.

Gate the host in a debug source set

Keep the remote fallback out of the release tree. A proposed Kotlin split looks like the following, and you should treat it as scaffolding rather than production networking.

// android/app/src/debug/java/com/example/inference/DebugInferenceHosts.kt
object DebugInferenceHosts {
    const val STAGING_BASE_URL = "https://staging.example.invalid/v1"
}

// android/app/src/release/java/com/example/inference/DebugInferenceHosts.kt
object DebugInferenceHosts {
    const val STAGING_BASE_URL: String? = null
}

fun inferenceBaseUrl(): String {
    val debugHost = DebugInferenceHosts.STAGING_BASE_URL
    check(BuildConfig.DEBUG && debugHost != null) {
        "Remote fallback is debug-only; use the on-device path."
    }
    return debugHost
}

Release compilation should fail closed if someone calls the remote path from shared code. You want a CI crash, not a silent production fallback that looks like an agent. React Native still needs the same fail-closed read on the JavaScript side.

// src/inference/host.ts
import { NativeModules } from "react-native";

export function getDebugInferenceHost(): string | null {
  if (!__DEV__) {
    return null;
  }
  return NativeModules.DebugInferenceHosts?.stagingBaseUrl ?? null;
}

If __DEV__ is false, do not read AsyncStorage for a leftover URL. Juniors often restore a session on first launch and rehydrate the debug host into a release candidate. That rehydrate path is how a rollback looks complete in git and still fails on device.

Stop writing the host into logcat

OkHttp logging is the usual gift inside a bugreport. Keep verbose loggers out of the main source set, and install them only from debug code. BASIC still prints the host, which is fine on a private phone and not fine in a zip you attach to a ticket.

val client = OkHttpClient.Builder()
    .apply {
        if (BuildConfig.DEBUG) {
            addInterceptor(HttpLoggingInterceptor().apply {
                level = HttpLoggingInterceptor.Level.BASIC
                redactHeader("Authorization")
            })
        }
    }
    .build()

For a hung voice call, log a local correlation id only. Never interpolate request.url. Never put the URL in Crashlytics keys, breadcrumb strings, or analytics events that survive process death.

Log.w("VoiceEval", "completion stalled; localSession=$localSessionId")

If your interceptor pretty-prints JSON bodies, disable it before you reproduce the hang. Body loggers will also retain prompt fragments, which is a separate leak from the host itself.

Reproducible bugreport grep

After the background hang, search the archive before you file anything. The commands below are the artifact; run them on the same device you used for the voice eval.

adb bugreport ./bugreport-first-hour.zip
mkdir -p /tmp/br && unzip -q ./bugreport-first-hour.zip -d /tmp/br

HOST="staging.example.invalid"
rg -n "$HOST" /tmp/br || echo "host not found in bugreport"

# Fail the first PR if release dex still contains the host
unzip -p app/build/outputs/apk/release/app-release.apk classes*.dex \
  | strings \
  | rg -n "$HOST" \
  && echo "FAIL: host survived release dex" \
  || echo "release dex is clean"

Pull preferences as well, because a clean dex does not mean a clean device.

adb shell run-as com.example.app \
  cat shared_prefs/inference.xml || true

adb shell run-as com.example.app ls files || true

If the XML still holds the host after you removed the constant, the first rollback is incomplete. Repeat the grep after uninstall and reinstall, not only after assembleRelease.

Lifecycle checks before you open the PR

Run these in order on one device. Record pass or fail, not impressions. Keep microphone state, network state, and power state in the PR body beside the diff.

Permission revoke. Open Settings → Apps → your app → Microphone → Don't allow, then resume the eval. The client should stop capture and must not dump the last request URL.
Backgrounding. With a live stream, press Home and wait thirty seconds. Resume and confirm you only logged localSessionId.
Process death. Run adb shell am kill com.example.app, relaunch, and confirm storage did not restore the debug host on a release-shaped build.
First rollback. Delete the debug host from the debug source set, assemble release, then grep dex and a fresh bugreport.

Decision table for hour one

Condition	Remote host allowed?	What you still grep
Debug flavor, mic granted, first hour	Staging only	bugreport zip, logcat, prefs
Debug flavor, mic revoked	None; stop capture	last request logs
Release candidate	None	APK strings, crash keys
After rollback tag	None	device prefs, leftover MMKV files

The table is a checklist, not a claim that every OEM dump looks identical. If a line fails, block the PR even when the feature demo still talks.

Where a throwaway host belongs

Hour one still needs somewhere to send a test completion when the on-device model is not packaged. Point the debug flavor at a host you control, not at production inference, and not at a laptop that will sleep during review. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode offers free model access and a free server option you can use as that disposable staging target while you prove the flavor gate, without borrowing production credentials. It does not replace on-device packaging, permission handling, or the grep steps, and this article does not claim model names, quotas, hardware, or uptime.

Limitations and who should skip this

This approach is debug-flavor scaffolding for a junior joining a mobile AI repo. It is the wrong path for customer audio, paid production inference, or any SKU that must stay on-device. Healthcare, offline-only catalogs, and anything covered by a signed model license should not use a free staging box as a fallback.

strings on dex can miss split URLs and obfuscated concatenation, so a clean grep is necessary rather than sufficient. iOS sysdiagnose is a different artifact, and you should not assume the Android zip search transfers. This article also skips energy numbers, because a leak test is not a battery benchmark.

First rollback, then open the PR

Your first PR should include the flavor files, the fail-closed React Native read, the log redaction, and a note of the bugreport grep. The description should record device, OS, permission state, network state, and whether the hung session recovered, restarted, or silently disappeared. After merge, run the rollback on a clean install once. If the host returns from disk, onboarding is not done; only the diff is.

If you run the same transition, reply with device, OS, the background and revoke steps, and whether the host recovered, restarted, or vanished from the next bugreport.

Keep Model Shards Out of Shared Storage on Your First Mobile AI PR

Roronoa — Sat, 12 Sep 2026 17:29:46 +0000

You clone the team's React Native repository onto a Pixel 8 running Android 15 with a half-charged battery. The README tells you to launch the sample, grant storage permission, and wait while an on-device model downloads. You background the app during that transfer, then reopen Files after a process death, and an incomplete shard sits in Downloads. That first-hour leak is the problem this article walks you through, before your first PR and before your first rollback.

This write-up is a proposed onboarding experiment, not a farm-wide benchmark and not a source of invented timings. You should record the device, OS, framework version, network, and permission state before you treat any observation as evidence. The goal is that model bytes stay in app-private storage across backgrounding, process death, and a later config rollback.

Why shared storage shows up in your first hour

Junior engineers often copy a DownloadManager snippet that targets the public Downloads collection because it appears to work. Android then indexes those files through MediaStore, and Files or a USB cable can list every incomplete shard. iOS has a quieter version of the same mistake when you write into a shared container or skip the backup exclusion flag.

On-device inference makes the blast radius worse than a misplaced JSON configuration sitting in a cache directory. Model shards are large, sometimes user-specific after packaging, and they survive the activity that downloaded them. A first rollback of the model URL does not delete public files the operating system already indexed. Your first hour on the repo is exactly when those leftovers show up in a demo that still looks fine.

Watch for these first-hour smells in the sample you just cloned:

The sample requests READ_MEDIA_IMAGES or another broad storage grant only to fetch a model.
DownloadManager.Request calls setDestinationInExternalPublicDir toward public Downloads.
React Native react-native-fs writes into DownloadDirectoryPath or ExternalStorageDirectoryPath.
iOS code copies a downloaded weight into a document the user can browse inside Files.
A retry queue keeps .gguf.part or .tflite.tmp sitting beside the finished file.

Coding assistants are everywhere in onboarding chats this year, which makes the leak easier to spread. A teammate pastes the downloader, the assistant repeats the public-path snippet, and your first PR ships the same Files.app surprise. Treat the assistant as a reviewer of a private destination helper, not as a source of storage permissions.

Proposed first-hour experiment

Label this as a procedure you run on one device, then compare notes with a teammate who owns a different OS build. Do not treat the steps as proof that every OEM Files app hides app-specific external directories the same way. Fill the environment block with the hardware on your desk before you file a bug.

Example environment to record

Device: Pixel 8 or iPhone 15, with the actual board name if you have it.
OS: Android 15 or iOS 18, plus the security patch string on Android.
App: React Native 0.76, Flutter 3.24, or whatever your lockfile pins today.
Network: Wi-Fi first, then a mid-transfer switch onto cellular.
Power: battery saver off, then on, without inventing drain percentages.
Permissions: storage or photos granted at launch, then revoked from Settings.
Application state: foreground download, Home, process death, then a cold relaunch.

Exact steps

Install a debug build from a clean profile so leftover models are not already present on disk.
Start the model download, then press Home while the progress affordance is still active.
Force-stop the app from Settings so you simulate process death in the middle of the transfer.
Open the system Files app and search for the model name, .part, .tmp, .gguf, and .tflite.
Connect adb or Finder and list public Downloads beside the app-specific models directory.
Restore the previous model URL as your first config rollback, then relaunch the app.
Search Files again and write down whether the incomplete shard recovered, restarted, or silently remained.

Expected observations, not measured claims

Public Downloads should contain zero model shards after a correct implementation lands in your first PR. App-private storage may still contain a truncated file, and your loader must refuse that file until a checksum matches. Rollback should not resurrect a public MediaStore row for the old URL after the force-stop. A permission revoke should stop a new public write rather than strand a world-readable temp file beside the old shard.

Commands you can run during that hour

# Android: public Downloads versus app-private models
adb shell ls -la /sdcard/Download | grep -E 'gguf|tflite|onnx|part|tmp'
adb shell run-as com.example.app ls -la files/models

# Android: MediaStore hits for model-like names
adb shell content query --uri content://media/external/file \
  --projection _display_name:_data:size \
  --where "_display_name LIKE '%.gguf%' OR _display_name LIKE '%.tflite%'"

# iOS Simulator: Application Support versus user-visible Documents
xcrun simctl get_app_container booted com.example.app data
# then inspect Library/Application Support/models and Documents

If a shard appears in the public tree, stop shipping the downloader and treat the path as a first-PR defect. Capture the listing in the ticket, but strip other apps' filenames before you paste anything into chat.

First PR: move the handoff into app-private storage

Your first PR should not add a new model flavor or a new prompt template. It should change the destination, the integrity check, and the rollback cleanup so reviewers can reason about filesystem side effects. Keep the diff small, and put the experiment steps into the pull-request template so the next junior repeats them.

Android destination

Avoid public DownloadManager destinations even when the sample looks shorter that way. Prefer internal storage or getExternalFilesDir, which is removed on uninstall and stays out of the default Files view on stock Android. If you still need DownloadManager for retries, point it at that private tree and hide the notification so the filename is not a user-visible attachment.

// Proposed helper — unexecuted example, adapt to your module.
fun modelDir(context: Context): File {
    val dir = File(context.filesDir, "models")
    if (!dir.exists()) dir.mkdirs()
    return dir
}

fun enqueuePrivateDownload(context: Context, url: String, fileName: String): Long {
    val request = DownloadManager.Request(Uri.parse(url))
        .setAllowedOverMetered(false)
        .setNotificationVisibility(DownloadManager.Request.VISIBILITY_HIDDEN)
        .setDestinationInExternalFilesDir(context, null, "models/$fileName")
    // Never call setDestinationInExternalPublicDir(DIRECTORY_DOWNLOADS, fileName)
    val dm = context.getSystemService(DownloadManager::class.java)
    return dm.enqueue(request)
}

fun isCompleteModel(file: File, expectedSha256: String): Boolean {
    if (!file.exists() || file.length() == 0L) return false
    val digest = MessageDigest.getInstance("SHA-256")
    file.inputStream().use { input ->
        val buf = ByteArray(8192)
        while (true) {
            val n = input.read(buf)
            if (n <= 0) break
            digest.update(buf, 0, n)
        }
    }
    val actual = digest.digest().joinToString("") { "%02x".format(it) }
    return actual.equals(expectedSha256, ignoreCase = true)
}

If you must use WorkManager instead of DownloadManager, write to the same private directory and delete the temp name in finally. Do not let a retry promote a partial file into MediaStore.Downloads because the worker lost its foreground window.

iOS destination

Put weights in Application Support, mark the directory excluded from backup, and refuse to load a file that failed checksum after a kill. Documents looks convenient during a demo, and that convenience is how Files.app grows a copy of your speech or vision weights. Complete file protection is not a substitute for the backup exclusion flag, so you set both.

// Proposed helper — unexecuted example.
func modelDirectory() throws -> URL {
    let base = try FileManager.default.url(
        for: .applicationSupportDirectory,
        in: .userDomainMask,
        appropriateFor: nil,
        create: true
    )
    let dir = base.appendingPathComponent("models", isDirectory: true)
    try FileManager.default.createDirectory(at: dir, withIntermediateDirectories: true)
    var values = URLResourceValues()
    values.isExcludedFromBackup = true
    var mutable = dir
    try mutable.setResourceValues(values)
    return dir
}

func persistModel(data: Data, name: String, expectedSHA256: String) throws -> URL {
    let dest = try modelDirectory().appendingPathComponent(name)
    let tmp = dest.appendingPathExtension("tmp")
    try data.write(to: tmp, options: [.atomic, .completeFileProtection])
    let digest = SHA256.hash(data: data).map { String(format: "%02x", $0) }.joined()
    guard digest == expectedSHA256.lowercased() else {
        try? FileManager.default.removeItem(at: tmp)
        throw NSError(domain: "model", code: 1)
    }
    _ = try FileManager.default.replaceItemAt(dest, withItemAt: tmp)
    return dest
}

React Native glue

Juniors often inherit react-native-fs samples that default to the downloads collection because those samples were written for user-picked photos. Pin the path to DocumentDirectoryPath on iOS and to internal files on Android, then promote a .tmp file only after the hash matches. Set background: false on this first PR unless you already have a tested background transfer policy for killed downloads.

import RNFS from 'react-native-fs';

export const modelDir = `${RNFS.DocumentDirectoryPath}/models`;

export async function downloadModel(url, fileName, expectedSha256) {
  await RNFS.mkdir(modelDir);
  const dest = `${modelDir}/${fileName}`;
  const tmp = `${dest}.tmp`;
  const result = await RNFS.downloadFile({
    fromUrl: url,
    toFile: tmp,
    background: false,
    discretionary: false,
  }).promise;
  if (result.statusCode !== 200) {
    await RNFS.unlink(tmp).catch(() => {});
    throw new Error(`download failed: ${result.statusCode}`);
  }
  const sha = await RNFS.hash(tmp, 'sha256');
  if (sha.toLowerCase() !== expectedSha256.toLowerCase()) {
    await RNFS.unlink(tmp);
    throw new Error('checksum mismatch; refusing to promote shard');
  }
  if (await RNFS.exists(dest)) await RNFS.unlink(dest);
  await RNFS.moveFile(tmp, dest);
  return dest;
}

Flutter path on the same first PR

Flutter teams hit the same handoff with path_provider when a tutorial writes weights into getDownloadsDirectory(). Use getApplicationSupportDirectory() for the durable model, write a sibling .tmp, and delete that sibling if the isolate dies. Do not request photos or media permissions for a file the UI never shows to the user.

// Proposed helper — unexecuted example.
Future<File> modelFile(String name) async {
  final support = await getApplicationSupportDirectory();
  final dir = Directory('${support.path}/models');
  if (!await dir.exists()) {
    await dir.create(recursive: true);
  }
  return File('${dir.path}/$name');
}

First rollback: leftover shards are the real regression

A config rollback that only swaps a remote URL is incomplete for an on-device packager. You also need to refuse truncated files and delete temp names that the previous build created in private storage. Public leftovers are worse, because MediaStore keeps serving them after your feature flag goes dark.

export async function rollbackModels(keepName) {
  if (!(await RNFS.exists(modelDir))) return;
  const entries = await RNFS.readDir(modelDir);
  for (const entry of entries) {
    const stale =
      entry.name.endsWith('.tmp') ||
      entry.name.endsWith('.part') ||
      entry.name !== keepName;
    if (stale) {
      await RNFS.unlink(entry.path);
    }
  }
}

Run the first-hour experiment again after that rollback lands on the same device. Confirm Files and MediaStore still show nothing for the old name, even when you search by extension only. Confirm the app does not load keepName if the checksum no longer matches the rolled-back manifest. Confirm a killed download does not leave a world-readable notification attachment with the model filename still visible.

If the old shard silently remains, that is a ship blocker even when the chat UI looks healthy. Write the listing into the rollback ticket, and keep the PR focused on deletion plus the load-time checksum rather than on a new model architecture.

Review the downloader without pasting device logs

Onboarding week is when people paste adb logcat and full path dumps into a public chat window. Those dumps include install paths, account names, and sometimes the model URL with a query token still attached. You want a second reader on the storage helper, not a copy of the bugreport traveling through someone else's retention policy.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source coding assistant with free model access and a free server option, which is enough for a junior to review a redacted downloader on a workspace you control. Paste the destination helper, the checksum function, and the rollback cleaner. Do not paste sysdiagnose output, Logcat, or a raw content query that includes other apps' files.

A useful prompt for that review looks like the block below, and you should keep the device listing out of it.

You are reviewing a mobile on-device model downloader.
Flag any path that lands in public Downloads, MediaStore, or user-visible Files.
Flag missing checksums, missing .tmp cleanup, and backup exclusion flags.
Assume Android 15 and iOS 18. Do not suggest broad storage permissions.

The assistant is a reviewer, not a substitute for the Files and adb steps above. If the model names a public directory, you still run the search yourself on the handset you used for onboarding.

Decision table for the first PR

Signal you see in the first hour	Ship the PR?	Required change
Shard in `/sdcard/Download` or Files	No	Private dir plus deletion of public copies
`.tmp` next to a loadable model	No	Refuse load until checksum matches
Broad media permission only for models	No	Drop the permission; use app storage
Rollback leaves old URL file on disk	No	Rollback job deletes non-keep names
Private dir, checksum, no Files hit	Yes	Add the experiment to the PR template

Use the table during review so the discussion stays on filesystem side effects. Do not expand the PR into a cloud-versus-edge architecture debate while public shards still exist.

Limitations and who should skip this

This approach is for apps that actually download or unpack on-device weights on phones you can hold. You should not treat the snippets as OEM-certified, and you should not copy them into a web-only agent that never writes a shard. Skip or adapt the workflow when any of the following is true for your repo.

Your model is compiled into the App Bundle or IPA and never hits the network after install.
You already stream embeddings from a server and store nothing durable on the device.
Your compliance team requires MDM-managed volumes that this article does not describe.
You cannot reproduce Files or MediaStore access on the training devices you own.

This article does not claim battery numbers, download speeds, or that every Android skin hides getExternalFilesDir equally well. Samsung, Xiaomi, and other OEM Files apps can still surface app-specific external files after a search. Re-run the listing on the device class your users actually hold, and record that OEM name beside the OS version.

What to send back

If you run the experiment, reply with the device, OS, framework version, and the lifecycle transition you used. Say whether the leftover shard recovered, restarted from zero, or silently remained after the first rollback. That single-device note is more useful than a generic mobile-AI architecture thread, and it tells the next junior whether your private-directory handoff actually survived process death.