DEV Community: Ashwar Sadh

Same audio, four request IDs: keying idempotency on the bytes so a phone can resend safely

Ashwar Sadh — Fri, 06 Nov 2026 06:16:34 +0000

Bolo turns speech on a phone into text. In cloud mode the phone records a voice note, uploads it to a small proxy, and the proxy calls a speech-to-text service. Two problems in that path turned out to be the same problem seen from opposite ends:

The server was doing the same transcription several times for one recording.
On a flaky home connection the phone gave up too early, even though a resend would have worked.

The fix for the second one is only safe because of the fix for the first. This post walks through both.

Disclosure: I'm the developer of Bolo, and this post is published from my account. It was written and published by an AI agent working on my behalf.

Problem 1: an idempotency key that never matched

The proxy already had an idempotency guard. The client sent an X-Bolo-Request-Id header, and a repeat of the same ID was supposed to return the first result instead of calling the speech service again.

The logs from 31 real dictations on one phone showed it collapsed nothing. One recording had been uploaded four times, with identical bytes, two of the uploads 44 ms apart. Each upload carried a fresh request ID, because the app minted a new UUID per call. Four IDs, four upstream calls, four quota charges. About 13% of the uploads in that sample were redundant.

The root cause on the phone was a race between two code paths that could both send the same recording, and that was fixed in the app. But an app build that is already installed cannot be patched from the server, so the server needed its own net.

Key on what the work is, not on what the client calls it

The question idempotency answers is "have I already done this piece of work?". For a transcription, the work is defined by who sent it and what audio it is. The request ID is just a label the client chose.

So the key became the device plus a SHA-256 of the uploaded bytes:

const serverAudioHash = crypto.createHash('sha256').update(req.file.buffer).digest('hex');
const suppliedAudioHash = String(req.headers['x-bolo-audio-sha256'] || '').toLowerCase();
if (suppliedAudioHash && suppliedAudioHash !== serverAudioHash) {
    return res.status(400).json({ error: 'audio hash mismatch' });
}

const idempotencyKey = `${deviceId}:audio:${serverAudioHash}`;
const execution = await transcriptionIdempotency.execute(
    idempotencyKey,
    serverAudioHash,
    () => transcribe(req.file /* , ... */)
);

Two choices worth pointing out:

The server computes the hash itself. The client may send its own hash, and a mismatch is rejected with 400, which catches a truncated upload. But the key is always built from the server's hash, so a client cannot claim someone else's cached result by sending a made-up hash.
The device is part of the key. Two different users dictating the same short phrase do not share a cache entry, even if their audio happened to be byte-identical.

The request ID is still logged on every line. It just no longer decides identity.

The store: share the promise, cache only success

class IdempotencyStore {
    constructor({ ttlMs = 10 * 60 * 1000 } = {}) {
        this.ttlMs = Math.max(1000, Number(ttlMs) || 10 * 60 * 1000);
        this.entries = new Map();
    }

    async execute(key, audioHash, operation) {
        this.cleanup();
        const existing = this.entries.get(key);
        if (existing) {
            if (existing.audioHash !== audioHash) {
                const error = new Error('Request ID was already used for different audio');
                error.statusCode = 409;
                throw error;
            }
            return { value: await existing.promise, deduplicated: true };
        }

        const entry = { audioHash, expiresAt: Date.now() + this.ttlMs, promise: null };
        entry.promise = Promise.resolve().then(operation);
        this.entries.set(key, entry);
        try {
            return { value: await entry.promise, deduplicated: false };
        } catch (error) {
            // Failed attempts are retryable with the same key; only completed work is cached.
            this.entries.delete(key);
            throw error;
        }
    }

    cleanup(now = Date.now()) {
        for (const [key, entry] of this.entries.entries()) {
            if (entry.expiresAt <= now) this.entries.delete(key);
        }
    }
}

What makes this work for the "two uploads 44 ms apart" case:

The entry is stored before the work finishes. The second upload finds the first one's promise and awaits it. It does not start a second upstream call, and it gets the same text as soon as the first finishes.
Failure removes the entry. If the speech service errors, the next attempt with the same audio runs fresh. Caching an error would turn one bad moment into ten minutes of failures.
A ten-minute TTL. Long enough to cover any realistic retry storm from one recording, short enough that the map stays small. It is in memory, so a restart clears it, which is acceptable: the worst case is one repeated call.
The 409 branch is a safety check left from the request-ID design: the same key with different audio is a contradiction. With the key now derived from the audio hash it should never fire, and if it ever does, it means the key construction has a bug.

Problem 2: giving up on a link that was only flaky

A later report came from a home connection: a 24-second note timed out, the single automatic retry died after 5 seconds, and a manual resend went through and was transcribed in 1.5 seconds. The audio was fine and the server was fine. The client simply did not resend patiently enough.

With the server-side key in place, resending the same audio is harmless. If the earlier upload did land, the resend gets the cached text: no second speech call, no second quota charge. So the app can afford to try harder:

object TranscriptionResend {
    const val MAX_ATTEMPTS = 4                       // including the first
    val BACKOFF_MS = listOf(2_000L, 5_000L, 10_000L) // before attempts 2, 3, 4
    const val RESEND_WINDOW_MS = 90_000L             // no new attempt after this

    fun isTransient(e: Throwable): Boolean = when (e) {
        is VoxException -> false                     // the app's own "this request is wrong"
        is java.net.UnknownHostException -> true
        is java.io.IOException -> !isCallCancelled(e)
        is retrofit2.HttpException -> e.code() in TRANSIENT_HTTP
        else -> false
    }

    // 500-504 from the proxy or nginx; 520-524 are Cloudflare's "origin did not answer in time".
    private val TRANSIENT_HTTP = setOf(500, 502, 503, 504, 520, 521, 522, 523, 524)

    // OkHttp reports its own cancel (the user tapped stop) as IOException("Canceled").
    private fun isCallCancelled(e: java.io.IOException) =
        e.message.equals("Canceled", ignoreCase = true)
}

And the loop:

suspend fun <T> run(
    nowMs: () -> Long = System::currentTimeMillis,
    sleep: suspend (Long) -> Unit = { delay(it) },
    block: suspend (attempt: Int) -> T
): T {
    val startedAt = nowMs()
    var attempt = 1
    while (true) {
        try {
            return block(attempt)
        } catch (e: Exception) {
            currentCoroutineContext().ensureActive()
            val pause = BACKOFF_MS.getOrElse(attempt - 1) { BACKOFF_MS.last() }
            val outOfTime = nowMs() - startedAt + pause > RESEND_WINDOW_MS
            if (!isTransient(e) || attempt >= MAX_ATTEMPTS || outOfTime) throw e
            attempt++
            sleep(pause)
        }
    }
}

The rules it encodes:

Only link failures are retried. A 4xx, or the app's own validation error, means resending the same thing gives the same answer.
A user's cancel is never retried. ensureActive() rethrows if the coroutine was cancelled, and OkHttp's own "Canceled" IOException is treated as final. The original bug report included "I pressed retry and it cancelled", so a stop must mean stop.
A time budget, not only a count. Four attempts with growing pauses, but no new attempt once 90 seconds have passed since the first. A person waiting for text will not wait forever.
Clock and sleep are parameters, so the whole policy is a fast unit test with a fake clock.

A read timeout that scales with the note

One more piece: a fixed 30-second read timeout cut off slow but healthy answers for long notes. The timeout is now 30 s plus half the note's length, capped at 2 minutes, applied by an OkHttp interceptor that reads the duration header the upload already carries:

fun readTimeoutMsFor(audioDurationMs: Long): Long =
    (30_000L + audioDurationMs.coerceAtLeast(0L) / 2).coerceIn(30_000L, 120_000L)

Other calls keep the client's default timeouts.

Takeaways

An idempotency key should describe the work, not the request. For uploads, a content hash plus the caller's identity is often the right key.
Compute the hash on the server; treat any client-supplied hash as a check, not as the key.
Store the in-flight promise so concurrent duplicates share one call, and cache only successful results.
Server-side idempotency is what makes aggressive client resends safe. Build it first.
Retry link failures only, never a user's cancel, and bound retries by time as well as by count.

Bolo is on Google Play as "Bolo AI Voice Typing & PC Sync" (search "Bolo AI"): https://play.google.com/store/apps/details?id=com.ashwar.bolo&utm_source=devto&utm_medium=article&utm_campaign=2026-w45-idempotency. Cloud dictation has a limited free cloud trial, and you can also bring your own OpenAI or Gemini key, or use offline on-device dictation.

A button on the lock screen must not open a chat: an unlock trampoline on Android

Ashwar Sadh — Fri, 06 Nov 2026 06:15:25 +0000

QuickDial puts a small chat button next to a normal phone call, so you can jump from the call to a chat with that number without saving it. Calls often come in while the phone is locked, so in QuickDial's source the button can also be tapped on the lock screen. That raised a question I had to answer before shipping it: what happens to the chat when somebody else is holding your phone?

The answer had to be "nothing opens until the phone is unlocked". This post is about the small, invisible activity that enforces that.

Disclosure: I'm the developer of QuickDial, and this post is published from my account. It was written and published by an AI agent working on my behalf. QuickDial is an independent app, not affiliated with WhatsApp LLC or Meta.

The risk

A chat screen shows message history, names, photos and documents. A button that is reachable on a locked phone and opens that screen directly would turn a convenience into a privacy leak: anyone who picks up the phone during a call could read the owner's conversations.

So the rule is simple to state:

The button may be visible on the lock screen.
The chat may only open after the user unlocks with their PIN, pattern or biometric.
If the unlock is cancelled or fails, nothing opens. Not the chat, not the app, not a half-loaded screen.

Decide at the call site

The service that handles the tap checks the keyguard first. If the phone is unlocked, the chat intent starts as usual. If it is locked, the same intent is wrapped and handed to a dedicated activity:

private fun startBehindUnlock(next: Intent) {
    val keyguard = getSystemService(Context.KEYGUARD_SERVICE) as KeyguardManager
    startActivity(
        if (keyguard.isKeyguardLocked) {
            UnlockThenOpenActivity.wrap(this, next)
        } else {
            next.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
        },
    )
}

Every path that opens a chat from the call button goes through this one function, including the screen where the user picks one of several numbers for a contact. One choke point means one place to get right.

The trampoline

UnlockThenOpenActivity has no layout of its own. It carries the real intent as an extra, shows itself over the lock screen, asks the system to dismiss the keyguard, and starts the real intent only from the success callback:

class UnlockThenOpenActivity : Activity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val next = nextIntent(intent) ?: run { finish(); return }

        val keyguard = getSystemService(Context.KEYGUARD_SERVICE) as KeyguardManager
        if (!keyguard.isKeyguardLocked) { launch(next); return }

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O_MR1) setShowWhenLocked(true)
        keyguard.requestDismissKeyguard(this, object : KeyguardManager.KeyguardDismissCallback() {
            override fun onDismissSucceeded() = launch(next)
            override fun onDismissCancelled() = finish()
            override fun onDismissError() = finish()
        })
    }

    private fun launch(next: Intent) {
        runCatching { startActivity(next) }
        finish()
    }
}

A few details carry the weight here:

The real intent is started in exactly one place. launch() is reached only when the phone was not locked to begin with, or from onDismissSucceeded(). Cancelled and error both call finish() and nothing else. When you review this kind of code, look for any other startActivity and treat it as a bug.

It re-checks the lock. The caller already checked, but by the time the activity is created the user may have unlocked with a fingerprint. Checking again avoids showing an unlock prompt for a phone that is already open.

requestDismissKeyguard lets the system own the unlock. The app never sees the PIN or the biometric. It shows the standard prompt, and the callback reports the result. Secure lock screens get the user's own credential check; a swipe-only lock screen just goes away.

It finishes on every path. A trampoline that stays alive after doing its job leaves an empty, see-through activity in the task, which looks like a frozen screen to the user.

The manifest entry matters as much as the code

<activity
    android:name=".ui.unlock.UnlockThenOpenActivity"
    android:exported="false"
    android:excludeFromRecents="true"
    android:noHistory="true"
    android:taskAffinity=""
    android:theme="@style/Theme.QuickDialCallBridge.Chooser" />

exported="false": no other app can send an intent to it and use it as a way to open arbitrary intents over the lock screen. This is the most important line in the file. A trampoline that takes "the next intent" as an extra must never be reachable from outside your app.
excludeFromRecents and noHistory: it never shows up in the recent-apps list and is not kept on the back stack, so pressing Back after the chat opens does not land on an invisible screen.
taskAffinity="": it does not join the app's main task, so unlocking does not pull the app's home screen forward behind the chat.
A translucent theme: the user sees the lock screen and then the system prompt, not a blank app window.

Reading the wrapped intent

Since Android 13 the type-safe getParcelableExtra(name, Class) is the right call; on older versions only the deprecated one exists:

private fun nextIntent(intent: Intent?): Intent? =
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
        intent?.getParcelableExtra(EXTRA_NEXT, Intent::class.java)
    } else {
        @Suppress("DEPRECATION")
        intent?.getParcelableExtra(EXTRA_NEXT)
    }

A missing extra finishes the activity at once. "Nothing to open" is a normal outcome, not a crash.

Version notes

The app's minimum SDK is 26, which is where requestDismissKeyguard arrived, so the API is always there. setShowWhenLocked arrived one release later, in 8.1 (API 27). On 8.0 exactly, the older window flag FLAG_SHOW_WHEN_LOCKED is the equivalent, and that version is worth a test on a real device if you support it.

Test it like an attacker would

Things I check by hand on a locked phone:

Tap the button, cancel the prompt: nothing opens, and the lock screen is still there.
Tap the button, fail the fingerprint several times until it falls back to PIN, then cancel: nothing opens.
Tap the button, unlock: the chat opens; Back goes to wherever the user was before, not to an empty screen.
Open Recents afterwards: no blank entry.
Phone already unlocked: no prompt at all, the chat opens straight away.

Takeaways

Showing a control on the lock screen and opening content from it are two separate permissions. Grant the first, gate the second.
Route every "open content" path through one function that checks the keyguard.
Let requestDismissKeyguard own the unlock, and start the real intent only from onDismissSucceeded().
A trampoline that forwards an intent must be exported="false".
Finish on every path, and keep the trampoline out of Recents and the back stack.

QuickDial is on Google Play as "QuickDial: Direct Chat & Call": https://play.google.com/store/apps/details?id=com.ashwar.quickdialbridge&utm_source=devto&utm_medium=article&utm_campaign=2026-w45-unlock. It works with WhatsApp and WhatsApp Business; independent app, not affiliated with WhatsApp LLC or Meta.

Binding to 127.0.0.1 is not enough: keeping a local control API away from the web pages in your own browser

Ashwar Sadh — Thu, 05 Nov 2026 06:17:27 +0000

Disclosure: I'm the developer of Relaymote, and this post is published from my account. It was drafted and published by an AI agent working on my behalf from the project's source code. Relaymote is unofficial; not affiliated with or endorsed by Anthropic.

Relaymote is an open-source (MIT) companion for Claude Code sessions on your PC. It runs a small daemon with a control API on 127.0.0.1: the CLI, the MCP tools and a tray icon all talk to it, and it serves a local dashboard. Some of those endpoints start and stop work on your computer, so "who may call this" matters.

The usual answer is "it only listens on loopback, so only this machine can reach it". That is true, and it is not the whole threat model. This post is the 38-line guard that closes the rest.

What loopback does not stop

Binding to 127.0.0.1 keeps other machines out. It does not keep out a web page running in your own browser on this machine. Two ways that goes wrong:

Blind cross-site requests. Any site you visit can make your browser send POST http://127.0.0.1:<port>/api/task with a form or fetch(..., {mode: 'no-cors'}). The page cannot read the response, but it does not need to: the request already did its work.
DNS rebinding. A site can point its own hostname at 127.0.0.1 after the page loads. The browser now treats http://evil.example:<port> as same-origin with the page, and the page can send requests and read the answers. The only trace on the server side is the Host header, which says evil.example:<port>.

CORS does not help with either. CORS controls who may read a response; it does not stop a simple POST from arriving, and under rebinding the browser thinks there is no cross-origin request at all.

What the legitimate callers look like

The fix starts with noticing that the real callers are easy to describe:

The CLI, MCP tools and tray are not browsers. They send no Origin header, and they address the port as 127.0.0.1, localhost or [::1].
The dashboard is a browser page, but it is served by the daemon itself, so its Origin is a loopback address on this same port.

Everything else is someone else.

The guard

const LOOPBACK = ['127.0.0.1', 'localhost', '[::1]'];

function allowedHost(value, port) {
  const v = String(value || '').trim().toLowerCase();
  return LOOPBACK.some(h => v === `${h}:${port}`);
}

/** Returns null when the request may proceed, or { status, body } to refuse it. */
function check(req, port) {
  const h = req.headers || {};
  if (h.host !== undefined && !allowedHost(h.host, port)) {
    return { status: 403, body: { ok: false, error: 'BAD_HOST' } };
  }
  const safe = req.method === 'GET' || req.method === 'HEAD' || req.method === 'OPTIONS';
  if (safe) return null;
  if (String(h['sec-fetch-site'] || '').toLowerCase() === 'cross-site') {
    return { status: 403, body: { ok: false, error: 'CROSS_ORIGIN' } };
  }
  if (h.origin !== undefined) {
    let ok = false;
    try { const o = new URL(String(h.origin)); ok = o.protocol === 'http:' && allowedHost(o.host, port); } catch {}
    if (!ok) return { status: 403, body: { ok: false, error: 'CROSS_ORIGIN' } };
  }
  return null;
}

It runs first in the request handler, before any routing:

const refused = require('./lib/control-guard').check(req, PORT);
if (refused) return json(res, refused.status, refused.body);

Three rules, in order:

Host must be loopback on this port, for every method. This is the rebinding defence, so it applies to GET too: a rebinding page reading /api/state is a leak even if it changes nothing. The comparison is exact (localhost:<port>, not "contains localhost"), so localhost.evil.example does not pass.
Safe methods stop there. GET, HEAD and OPTIONS change nothing, and the dashboard loads with them.
State-changing methods must not come from another site. Sec-Fetch-Site: cross-site is refused outright. If an Origin is present, it must parse as http: on a loopback host and this port. A missing Origin passes, because that is what the CLI looks like.

The edge cases the tests pin down

The test suite checks the cases that are easy to get wrong:

G('POST', { host: `127.0.0.1:${PORT}` })                                  // CLI / MCP: passes
G('POST', { host: `127.0.0.1:${PORT}`, origin: `http://127.0.0.1:${PORT}` }) // dashboard: passes
G('POST', { host: `127.0.0.1:${PORT}`, origin: 'https://evil.example' })  // CROSS_ORIGIN
G('POST', { host: `127.0.0.1:${PORT}`, origin: 'null' })                  // CROSS_ORIGIN
G('GET',  { host: `evil.example:${PORT}` })                               // BAD_HOST, even for GET
G('POST', { host: `localhost:${PORT}`, 'sec-fetch-site': 'cross-site' })  // CROSS_ORIGIN

Origin: null deserves a note. Sandboxed iframes, file:// pages and some redirects send the literal string null. It is not "no origin"; it is a browser telling you it will not say. new URL('null') throws, ok stays false, and the request is refused.

Two cheap extras on the dashboard

The dashboard response is sent with X-Frame-Options: DENY (so another page cannot frame it and trick clicks onto its buttons) and Cache-Control: no-store. Neither replaces the guard; both are one header each.

What this does not cover

It is not authentication. Any program already running as you on the same machine can call the API, exactly as it could read your files. The guard's job is narrower: a web page should not get the powers of a local program just because the browser happens to run on that machine. For a localhost API, that narrow job is the one most often skipped.

If you ship a local daemon with an HTTP control port (dev servers, desktop helpers, editor plugins), the checklist is short: exact loopback Host on every request, refuse Sec-Fetch-Site: cross-site on writes, and allow only your own loopback Origin or none.

Relaymote is on GitHub under the MIT licence. Unofficial; not affiliated with or endorsed by Anthropic.

Polling someone else's API politely: an interval that follows the vehicle's state, a per-user floor and one global token bucket

Ashwar Sadh — Thu, 05 Nov 2026 06:16:34 +0000

Disclosure: I'm the developer of ScooterLog, and this post is published from my account. It was drafted and published by an AI agent working on my behalf from the app's source code. ScooterLog is an independent app, not affiliated with, endorsed by or sponsored by Ola Electric.

ScooterLog keeps a charge history and a trip log for a connected electric scooter. There is no push feed to subscribe to, so the server polls the vehicle maker's cloud for each rider's scooter and stores what comes back. That cloud is not ours. Every request we send is a request someone else has to serve, and the fastest way to lose access to an upstream API is to look like a load test.

This post is the scheduler that decides when to ask. It is about 180 lines of Python, and most of it is four ideas.

1. The interval follows what the vehicle is doing

A parked scooter at midnight changes nothing for hours. A scooter on the charger gains a percent every few minutes. A scooter being ridden changes position and odometer every minute. Polling all three at one fixed rate is either wasteful or too slow.

So the next interval is chosen from the last two stored readings:

RIDING   = 60     # seconds
CHARGING = 180
PARKED   = 300
ASLEEP   = 1800

def next_interval(user_id, vehicle_id):
    pts = store.recent_points(user_id, vehicle_id, 2)
    if not pts:
        return PARKED
    last = pts[0]
    if last.get('charging_state') in ('SLOW_CHARGING', 'FAST_CHARGING'):
        return CHARGING
    if len(pts) == 2 and (_moved(pts[0], pts[1]) or
                          (pts[0].get('odometer') or 0) - (pts[1].get('odometer') or 0) >= 0.5):
        return RIDING
    ...
    return PARKED

"Moved" is deliberately coarse: a change of more than 0.0001 degrees in latitude or longitude (roughly 11 m), or half a kilometre on the odometer. GPS jitter on a parked vehicle should not flip it into riding mode.

2. Keep watching after the data goes quiet

The first version had a blind spot. Mid-ride, the upstream often sends nothing new: the last reading stays the "awake" one from the start of the ride. With only the rules above, the scheduler saw two identical readings, decided the scooter was parked, and backed off to five minutes. The end of the ride was then caught up to five minutes late.

The fix is one extra rule: if the last reading says the vehicle was awake, and it is less than 40 minutes old, keep polling at the riding rate.

AWAKE_MS = 40 * 60 * 1000

if not last.get('sleep') and time.time() * 1000 - (last.get('source_ms') or 0) < AWAKE_MS:
    return RIDING

The lesson generalises: when the source goes silent, "nothing changed" and "nothing was reported" look the same. Decide which one you are assuming, and bound how long you assume it.

3. A hard floor per user

Whatever the rules say, no user is polled more often than MIN_INTERVAL (60 seconds by default, set from an environment variable). The loop applies it after picking the fastest interval among that user's vehicles:

due_interval = min((next_interval(u['user_id'], v['id']) for v in vs), default=PARKED)
due_interval = max(MIN_INTERVAL, due_interval)
if now - (u['last_poll_ms'] or 0) >= due_interval * 1000:
    poll_user(u['user_id'])

The floor is a separate line on purpose. The adaptive rules will change as we learn; the floor is the promise to the upstream, and it should not depend on those rules being right.

4. One token bucket for the whole service

Per-user floors do not stop a spike. If many riders start charging at 7 pm, many users become "due" in the same tick. So every upstream request also takes a token from a single, service-wide bucket (20 requests per second by default):

class TokenBucket:
    def __init__(self, rate, burst=None):
        self.rate = rate
        self.capacity = burst or max(1.0, rate)
        self.tokens = self.capacity
        self.ts = time.monotonic()
        self.lock = threading.Lock()

    def take(self, timeout=30):
        deadline = time.monotonic() + timeout
        while True:
            with self.lock:
                now = time.monotonic()
                self.tokens = min(self.capacity, self.tokens + (now - self.ts) * self.rate)
                self.ts = now
                if self.tokens >= 1:
                    self.tokens -= 1
                    return True
            if time.monotonic() >= deadline:
                return False
            time.sleep(0.05)

Two details matter. It uses time.monotonic(), so a clock change on the server cannot mint a burst of tokens. And take() gives up after a timeout and returns False; the caller then skips that user for this tick instead of queueing forever. A skipped poll is picked up on the next pass. A queue that only grows is an outage in slow motion.

5. Stop on the first "no", and keep a kill switch

Two smaller rules finish the picture. A 401 or 403 from upstream marks that user as needing to sign in again and stops polling them; retrying a rejected token on a timer helps nobody. And the main loop checks a kill switch before each pass: when it is on, the service makes no upstream calls at all and just sleeps.

while not (stop and stop.is_set()):
    if upstream.disabled():   # kill switch: no upstream calls at all
        time.sleep(30)
        continue
    ...

What it costs

Readings can lag by up to the current interval, so a charge alarm can arrive a few minutes after the battery reaches the level. The app says so: it only knows what the scooter reports, and readings can lag a few minutes. It does not control the scooter, and it is not meant for emergencies.

If you poll an API you do not own, the transferable parts are: choose the interval from state, keep watching for a bounded time when the data goes quiet, put a fixed floor per user under the clever rules, and put one monotonic token bucket in front of everything. The app is on Google Play.

ScooterLog is an independent app, not affiliated with, endorsed by or sponsored by Ola Electric.

A heartbeat that goes quiet when the route is dead: signed presence records with a short TTL

Ashwar Sadh — Wed, 04 Nov 2026 06:19:13 +0000

Disclosure: I'm the developer of the app described here, and this post was drafted and published by an AI agent from the project's source code.

Bolo (search Bolo AI on Google Play) turns an Android phone into a microphone for a computer. On the same Wi-Fi the phone finds the PC directly. Away from it, the PC's Node.js helper publishes a small "I'm here, reach me at this URL" record that the phone looks up. This post covers src/presence.js, the 146-line module behind that record, and four decisions in it.

1. Sign the record, don't trust the transport

The helper generates an EC key pair (prime256v1) once and keeps it in its settings file. The server ID is the SHA-256 of the public key, so identity is the key, not a name anyone can claim.

Each record is signed over a canonical, newline-joined payload of fixed fields in a fixed order (server ID, URL, display name, version, boot ID, reported-at, expires-at, lookup-token hash):

record.signature = crypto.sign(
  'sha256',
  Buffer.from(canonicalPresencePayload(record), 'utf8'),
  identity.privateKey
).toString('base64');

Signing a canonical string instead of JSON.stringify(record) matters: key order and whitespace in JSON are not guaranteed to survive a round trip, and a signature check that depends on them fails for no good reason.

The phone looks the PC up by a random lookup token, but the record stores only its hash, so the lookup service holds nothing that lets it replay the lookup.

2. Short TTL, steady heartbeat

Records expire after 150 s and the helper re-sends every 45 s: three chances to refresh before a record lapses. A PC that is switched off just stops sending and falls out of the lookup on its own, with no "goodbye" message to lose. The interval timer is unref()ed so the heartbeat never keeps the process alive by itself.

3. Publish only while the route works

This is the fix that taught me the most. A record for a tunnel URL that no longer reached the PC made the phone show the PC as online, and then every tap failed. The refresh now asks a health check first:

async function publishPresence() {
  if (!currentTunnelUrl || !currentVersion) return false;
  if (!routeHealthy()) return false;
  ...
}

routeHealthy is injected (setRouteHealthCheck) and defaults to "yes", which keeps the module testable. When the probe says the URL does not reach this machine, the helper stays silent, the old record expires within the TTL, and the phone sees "offline", which is true. Absence of a record is more honest than a stale one.

4. Say who said no

A rejected refresh now logs who rejected it. The service answers with JSON; an edge bot-challenge answers with HTML. So the log line is either proxy: {...} or edge (cf-mitigated=..., ray=...). On one CI runner on a datacenter network, the edge had answered a bare https.request with a bot challenge while fetch from the same machine got a 200. Home networks passed both. The module now uses fetch with a 10 s AbortSignal.timeout, and the log makes the next such difference diagnosable in one line instead of a guessing game.

Takeaways

Make identity a key; sign a canonical string, not serialized JSON.
Short TTL plus a faster heartbeat beats explicit "I'm gone" messages.
Gate publishing on a real reachability check; a missing record beats a stale one.
Log which layer rejected you.
Inject the health check so the module stays testable.

Bolo is on Google Play (search Bolo AI): https://play.google.com/store/apps/details?id=com.ashwar.bolo. The presence record carries only a server ID, a URL, a display name and version info, signed by the PC's own key; it does not carry dictated text.

A share-target Activity that must not run twice: why it finishes itself when Android restores it

Ashwar Sadh — Wed, 04 Nov 2026 06:18:03 +0000

Disclosure: I'm the developer of the app described here, and this post was drafted and published by an AI agent from the project's source code.

Auto UPI QR lives in the Android share menu. You share a QR picture (or a upi:// link as text) to it, it reads the payee details, and it hands the link to your own UPI app. The entry point is a 61-line Activity. Most of it is routine; one line is there because of what happens when Android takes the Activity away and brings it back.

The restore problem

A share-target Activity is launched with an Intent carrying the shared image. If the system kills your process while the Activity is in the background (low memory, the user switching apps for a while), Android recreates the Activity later, and onCreate runs again with the same original intent, plus a non-null savedInstanceState.

For an Activity that shows a picture, that is fine. For one that acts on the intent, it means the action can run a second time with nobody having asked. For a payment-adjacent flow that is the wrong default: the user comes back to the phone and a pay sheet for an old QR appears out of nowhere.

One line

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    if (savedInstanceState != null) { finish(); return }
    ...
}

A fresh share always arrives with savedInstanceState == null. A restore never does. So the rule is: act only on a fresh launch, and close quietly on a restore. If the user still wants to pay, sharing the QR again takes two taps, and that second share is a deliberate act.

The rest is dispatch by what was shared

when {
    action == Intent.ACTION_SEND && type.startsWith("image/") -> {
        val uri = streamUri(intent) ?: return finish()
        handleImage(uri)
    }
    action == Intent.ACTION_SEND && type.startsWith("text/") -> {
        val qr = UpiQr.findIn(intent.getStringExtra(Intent.EXTRA_TEXT))
        if (qr == null) { toast(R.string.toast_no_upi_qr); finish() }
        else paySheet.handle(qr) { finish() }
    }
    else -> finish()
}

Three small decisions are worth copying:

Unknown shape means finish. Anything that is not an image or text send goes to else -> finish(). A share target should never sit open on an intent it doesn't understand.
Every path ends in finish(). Found, not found and error all close the Activity (the success path closes via the pay-sheet callback). There is no state where an invisible Activity lingers in the back stack.
Distinct outcomes, distinct messages. Scanning returns a sealed result: Found, NoUpiQr or Error. "This picture has no UPI QR" and "something went wrong reading it" are different toasts, because they lead to different next steps for the user.

The Parcelable API split

EXTRA_STREAM is read differently on newer Android:

private fun streamUri(intent: Intent): Uri? =
    if (Build.VERSION.SDK_INT >= 33) intent.getParcelableExtra(Intent.EXTRA_STREAM, Uri::class.java)
    else intent.getParcelableExtra(Intent.EXTRA_STREAM)

The typed overload (API 33+) checks the class for you; the old one is deprecated, hence the narrowly scoped @Suppress("DEPRECATION") on this one function instead of the whole file. A null Uri is simply finish().

Scanning off the main thread

handleImage launches in lifecycleScope and calls the scanner as a suspend function. Because the scope is tied to the Activity, a user who backs out mid-scan cancels the work rather than leaving it to call paySheet.handle on a dead Activity.

Takeaways

A share target that acts on an intent should act only when savedInstanceState == null.
Make "I don't understand this", "nothing found" and "failed" three different exits.
Finish on every path; never leave an invisible Activity behind.
Scope the coroutine to the lifecycle so back-out cancels the scan.
Confine @Suppress("DEPRECATION") to the one function that needs it.

Auto UPI QR is on Google Play: https://play.google.com/store/apps/details?id=com.ashwar.autoupiqr. It reads UPI QR codes from images and hands them to your own UPI app; it is not a bank and never sees your PIN. The restore-safe share handling and pay sheet described here are in the source for the next version; I don't claim which Play build contains them. Always check the payee name before entering your UPI PIN.

The caller's number was a timestamp: picking a phone number out of an Android call notification

Ashwar Sadh — Tue, 03 Nov 2026 06:16:44 +0000

A user was on a normal phone call with a saved contact, tapped QuickDial's in-call chat button, and the chat app answered with "+911792056181499 is not a valid phone number". The contact had a perfectly good number. This post is about where that 13-digit number came from, and the three small rules that now decide which digits in a call notification are the caller's.

How the app sees a call

QuickDial does not read the call log. During a cellular call it reads the dialer's ongoing-call notification through a NotificationListenerService: the title is usually the contact name or the number, and the app turns that into a number for a one-tap chat. When the title is a name, it looks the name up in contacts; when the visible text already holds a number, it uses that directly.

The bug was in "already holds a number". The listener turned every notification extra into text and took the first run of 8 to 15 digits as the number.

The 13 digits

1792056181499 is not a phone number. It is an epoch time in milliseconds: 15 October 2026, 14:53:01 IST, 37 seconds before the user's screenshot. The dialer keeps the call's start time in the notification's extras once the call connects.

That explained the odd detail in the report: a redial worked. On the redial the button was tapped before the call connected, so the timestamp extra did not exist yet, and the contact name won. After connecting, the timestamp appeared earlier in the text than anything else number-shaped, and it beat the name.

Lesson one, before any code: don't stringify a whole Bundle and regex it. Read the fields that are meant for display, in display order. But the fix also needed rules for what a number is, because display fields can carry junk too.

Rule 1: a recent epoch time is never a number

private const val TEN_YEARS_MS = 10L * 365 * 24 * 60 * 60 * 1000

fun looksLikeTimestamp(raw: String, nowMs: Long): Boolean {
    if (raw.trim().startsWith("+")) return false
    val digits = raw.filter(Char::isDigit)
    val asMs = when {
        digits.length == 13 -> digits.toLongOrNull()
        // Seconds: no Indian mobile and no NANP area code starts with 1.
        digits.length == 10 && digits.startsWith("1") -> digits.toLongOrNull()?.times(1000)
        else -> null
    } ?: return false
    return kotlin.math.abs(asMs - nowMs) <= TEN_YEARS_MS
}

13 digits within ten years of now is a millisecond time.
10 digits starting with 1 within ten years is a time in seconds. That shape is safe to reject because Indian mobile numbers don't start with 1, and neither does any North American area code.
Anything written with a leading + was formatted as a phone number by someone, so it is never treated as a time.
nowMs is a parameter, not System.currentTimeMillis() inside the function, so tests can pin the clock.

Rule 2: a direct number must be valid for its numbering plan

Not every digit run that isn't a time is a phone number either: a notification can carry other numbers that are not the caller's. So a direct number counts only if a validity check says it is a real number for its region (the app passes in a libphonenumber-style check):

fun directNumber(texts: List<String>, nowMs: Long, isValid: (String) -> Boolean): String? =
    texts.asSequence()
        .flatMap(::candidates)
        .firstOrNull { !looksLikeTimestamp(it, nowMs) && isValid(it) }

candidates() finds runs like +91 98xxx-xxxxx or (022) xxxx xxxx, keeps the digits and a leading +, and drops anything outside 8 to 15 digits. The validator is injected as a function, which keeps the object free of Android and phone-number library dependencies, so plain JVM unit tests cover it.

Rule 3: junk is not an identity either

The match engine has a shortcut: if the notification title "looks like a number", use it as the number instead of searching contacts by name. A field that is only a timestamp, or only an invalid digit run, must not take that shortcut:

fun isNumericNoise(text: String, nowMs: Long, isValid: (String) -> Boolean): Boolean {
    val trimmed = text.trim()
    if (trimmed.count(Char::isLetter) > 0) return false
    val runs = candidates(trimmed).toList()
    if (runs.isEmpty()) return false
    return runs.all { looksLikeTimestamp(it, nowMs) || !isValid(it) }
}

Any letter means it is a name, so it goes to the contact lookup. All digits and all junk means it is ignored, and the next field gets its turn.

Keep it pure, keep the defect in the comment

All three rules live in one internal object with no Android imports. The KDoc at the top records the actual defect: the error text, the timestamp, what it decoded to, and why the redial worked. The next person who wonders why a 13-digit number is rejected gets the reason without digging through history.

Takeaways

Read the notification fields meant for display, not every extra in the Bundle.
Phone numbers and epoch times overlap in length. Reject times near now, and let a leading + override.
Validate direct numbers against the numbering plan; length alone is not enough.
A field that is only noise should be skipped, not treated as an identity.
Inject the clock and the validator so the rules are plain unit tests.
When a retry works and the first try doesn't, ask what changed in the data between the two, not only in the code path.

QuickDial is on Google Play as "QuickDial: Direct Chat & Call": https://play.google.com/store/apps/details?id=com.ashwar.quickdialbridge&utm_source=devto&utm_medium=article&utm_campaign=2026-w45-timestamp. It works with WhatsApp and WhatsApp Business; independent app, not affiliated with WhatsApp LLC or Meta.

The desktop app you scrape updated overnight: a version watch that re-checks what you depend on, once per change

Ashwar Sadh — Tue, 03 Nov 2026 06:15:46 +0000

Disclosure: I'm the developer of the tool described here, and this post was drafted and published by an AI agent from the project's source code. Relaymote is unofficial; not affiliated with or endorsed by Anthropic.

Relaymote (MIT, Node.js) is a phone remote for Claude Desktop's Code-tab sessions. Desktop has no API for that, so Relaymote reads two things it does not own: the Code tab's sidebar (through the debugger port) and the session transcripts on disk. Both can change shape whenever Desktop or the Claude Code it bundles updates, and nobody sends you a changelog for the parts you scrape.

This post is about the small module that turns "it silently broke after an update" into one message on the day of the update: lib/claude-version-watch.js.

The failure that started it

One Desktop update (2.42304.2 to 3.1623.0) moved screen-reader-only status text inside each sidebar row's button. Relaymote read the row's text as the session title, so titles came out as " Awaiting input". 404 of 473 session titles were polluted before anyone noticed. Nothing crashed. Nothing logged an error. The data was just wrong.

The lesson is not "write a better selector". Selectors for someone else's UI will keep breaking. The lesson is: notice the update, run a live check of every surface you depend on, and say the result once.

Step 1: know the installed versions without asking the app

Both versions are visible on disk. Desktop installs into app-<version> folders and Claude Code into version-named folders, so the newest folder name is the installed version:

const cmpVer = (a, b) => {
  const x = String(a).split('.').map(Number), y = String(b).split('.').map(Number);
  for (let i = 0; i < Math.max(x.length, y.length); i++) {
    const d = (x[i] || 0) - (y[i] || 0); if (d) return d;
  }
  return 0;
};
const newest = (names) => names.filter(n => /^\d+(\.\d+)+$/.test(n)).sort(cmpVer).pop() || null;

Two details matter. Compare versions numerically, part by part: as strings, "3.999" sorts after "3.1623". And filter to names that look like versions, so a stray folder never becomes "the version".

Step 2: the live check names problems in plain sentences

check() does not compare against a stored snapshot of the UI. It asks questions whose answers must hold whatever the layout is:

Can we reach Desktop's debugger at all?
Did the sidebar read return any sessions? Zero rows means the session list moved.
Does any title match the known pollution pattern (/\s(Awaiting input|Unread response|Started (from|by) .*)$/)?
With 20 or more rows, does at least one show a status? If none do, the status labels changed.
Does the newest transcript parse, and does it contain record types we have never seen?

Each failure is pushed as a sentence someone can act on ("the Code tab sidebar read 0 sessions — Desktop changed its session list"), not as a stack trace.

Step 3: separate problems from notes

New transcript record types are common: Claude Code adds them regularly (api-request, cost-state and several others appeared between Claude Code 2.1.300 and 2.1.304). Relaymote skips unknown types safely, so a new type is a note, not a problem:

if (t.unknown.length)
  notes.push('new transcript record types (skipped safely): ' +
    t.unknown.map(([k, n]) => `${k}×${n}`).join(', '));

If every new record type raised an alarm, the alarm would be ignored by the second week. Keep "needs a fix" and "worth knowing" in different lists, and only the first makes the result not OK.

To find the types cheaply, it reads only the last 2 MB of the most recently modified transcript and drops the first (probably cut) line. That is enough to see what the current version writes.

Step 4: run on change, not on a schedule

The watch ticks every few minutes, but almost every tick is a no-op:

const was = load();
if (!was) { save({ ...now, at: new Date().toISOString(), checked: null }); return { first: true, now }; }
if (was.desktop === now.desktop && was.code === now.code && !was.pending) return null;

First sight only records. On a fresh install there is no "before", so there is nothing to report.
Same versions, nothing pending: return. The expensive live check runs only when a version actually changed.
One alert per change. After the check, the new versions are saved with the result, so the next tick is quiet again.

Step 5: don't blame the update for a restart

An update usually restarts Desktop, and for a minute the debugger is simply not up yet. Reporting "cannot reach Desktop" at that moment would be a false alarm on every single update. So if the only problem is the unreachable debugger, the change is parked as pending and retried, up to six ticks:

if (!r.ok && r.problems.every(p => /debugger link down/.test(p)) && (was.pendingTries || 0) < 6) {
  save({ ...was, pending: now, pendingTries: (was.pendingTries || 0) + 1 });
  return { waiting: true };
}

After six tries it reports anyway, because a debugger that never comes back is a real problem.

What the message looks like

One push notification, titled with what changed (Claude updated: Desktop <old> → <new>, Claude Code <old> → <new>, only the parts that changed) and a body that is either "everything it reads from Claude works" plus the notes, or the list of problems. The same line goes to the log. That is the whole output: no dashboard, nothing to open.

Takeaways

If you scrape or parse an app you don't own, its updates are your incidents. Detect them from the install on disk.
Check invariants ("some row has a status"), not a frozen copy of the UI.
Split problems from notes, or the alert becomes noise.
Run the expensive check once per version change, and record the result so it doesn't repeat.
Give a restart time to finish before calling it a failure, with a hard limit on how long you wait.

The code is in lib/claude-version-watch.js in the Relaymote repo, with its test in test/claude-version-watch.js. Relaymote is unofficial; not affiliated with or endorsed by Anthropic.

Check for updates always, restart only when nobody is typing: an idle gate for a self-updating Node.js helper

Ashwar Sadh — Mon, 02 Nov 2026 06:14:03 +0000

Disclosure: I'm the developer of the app described here, and this post was drafted and published by an AI agent from the project's source code.

Bolo turns an Android phone into a microphone for a computer: you speak on the phone and the text is typed at the cursor over local Wi-Fi. The computer side is a small Node.js helper in the tray. It updates itself, and updating means restarting, which is exactly what you must not do in the middle of someone's sentence.

This post is about the 91-line module that decides when the restart happens (src/updateGate.js), and the bug that made it necessary.

The first rule was too cautious

The original rule was simple: if a phone is connected, skip the update check. A phone mid-dictation should never see the helper vanish.

It held up until a helper was still on the previous version after a release had shipped. Its phone was simply always connected, so the check never ran. "Don't update while connected" quietly became "never update" for the most active users, who are the ones who most need fixes.

The lesson: "connected" is not "busy". A phone can sit connected for hours while nobody says a word.

Split the decision in two

The fix separates two things the old rule had glued together:

Checking for an update runs on its normal schedule (every 6 hours, plus on demand), whether or not a phone is connected.
Restarting waits until no text is being typed right now and none has been typed for 2 minutes.

Busy is measured where the typing happens. The message handler wraps every message that types text (a dictation, a live partial transcript, a clipboard paste) in a begin/end pair:

async function handleMessage(ws, message) {
  const typing = message.type === 'text'
    || message.type === 'realtime_text'
    || message.type === 'clipboard_paste';
  if (!typing) return handleMessageInner(ws, message);
  updateGate.begin();
  try {
    return await handleMessageInner(ws, message);
  } finally {
    updateGate.end();
  }
}

The finally matters: a dictation that throws still ends, so a failure can't leave the gate stuck "busy" forever.

The gate itself

Two pieces of state, a counter and a timestamp:

let lastActivityAt = 0;
let inFlight = 0;

function begin() { inFlight++; lastActivityAt = now(); }
function end()   { inFlight = Math.max(0, inFlight - 1); lastActivityAt = now(); }

function isIdle(idleMs = IDLE_MS) {
  return inFlight === 0 && now() - lastActivityAt >= idleMs;
}

A counter, not a boolean. Two messages can overlap (a partial transcript and the final text). With a boolean, the first end() would declare the gate idle while the second is still typing.
Math.max(0, …) so an unmatched end() can't push the counter negative and make "idle" impossible.
The clock is injectable (now), so the tests move time forward instead of sleeping for two minutes.

Waiting is a re-check loop that sleeps only as long as it has to:

function waitForIdle({ idleMs = IDLE_MS, pollMs = POLL_MS } = {}) {
  return new Promise((resolve) => {
    const check = () => {
      if (isIdle(idleMs)) return resolve();
      const t = setTimeout(check,
        Math.min(pollMs, Math.max(50, idleMs - idleForMs())));
      t.unref?.();
    };
    check();
  });
}

If 100 seconds of the 120 have already passed, it waits 15 seconds (the poll cap), not another full two minutes. unref() keeps a pending wait from holding the process open on its own.

One waiter at a time

The 6-hour timer keeps firing while an update waits for a quiet moment. Without a guard, a busy afternoon could stack several waiters, and the first quiet moment would trigger several restarts in a row. So there is exactly one pending update:

let pending = null;

async function runGatedUpdate({ version, check, apply, interactive, ... }) {
  if (pending) {
    if (interactive) log(`[Update] ${pending} will install at the next idle moment.`);
    return 'pending';
  }
  const result = await check(version);
  if (!result.enabled || !result.updateAvailable) return /* 'disabled' | 'current' */;
  pending = result.version;
  try {
    await waitForIdle();
    await apply(result);   // restarts the helper
    return 'applied';
  } finally {
    pending = null;
  }
}

The finally again: if apply fails (a download error, say), pending clears, and the next scheduled check can try again instead of being told forever that an update is "pending".

When you ask for an update check by hand while you're dictating, you get a plain answer ("will install at the next idle moment") instead of a restart under your cursor.

What I'd keep from this

Name the condition you actually care about. "Phone connected" was a stand-in for "user is typing", and the stand-in was wrong most of the day.
Separate detecting an update from applying it; only the second needs to wait.
Count in-flight work; don't flag it. Always release in finally.
Allow one pending action, and clear it on failure.
Make time injectable so a 2-minute rule is testable in milliseconds.

Bolo is on Google Play (search "Bolo AI"), and the Windows companion is on GitHub releases. The phone and the computer talk over your local Wi-Fi.

Real range from a scooter's battery readings: sum the kilometres, sum the percent, then divide

Ashwar Sadh — Mon, 02 Nov 2026 06:12:53 +0000

ScooterLog polls a connected electric scooter every few minutes and keeps the readings: battery percent, odometer, charging state. The number riders ask for most is "how far will a full charge actually take me?". This post is how that number is computed from the log, and the small decisions that stop it from being quietly wrong.

The raw material

Each stored reading is (source_ms, battery_soc, odometer, charging_state). The scooter's own timestamp is the primary key, so INSERT OR IGNORE makes polling idempotent: asking twice for the same reading writes one row.

A "cycle" is the ride between two charges: from the first reading after the charger is unplugged to the last reading before the next charge starts (or the newest reading, if no new charge has begun).

km  = max(0.0, b.odometer - a.odometer)
pct = max(0.0, a.soc - b.soc)
if km >= 1 and pct >= 1:
    km_per_pct = km / pct
    full_range = round(km_per_pct * 100)

Rule 1: do not divide tiny numbers

One kilometre that cost zero or one percent is noise: battery percent updates in steps. So a cycle only produces a ratio when it covers at least 1 km and used at least 1 %. Everything else still shows as a trip, but it does not feed the range figure.

Rule 2: sum first, divide once

With several cycles, the tempting average is the mean of each cycle's km/%. A 3 km errand that happened to drop 1 % reads as 3 km/%, and it counts as much as a 60 km day that dropped 30 % (2 km/%). The mean of ratios is dragged around by the short cycles.

The fix is to weight by distance: total kilometres divided by total percent.

cys = [s["cycle"] for s in sessions
       if s.get("cycle") and s["cycle"]["km"] >= 1 and s["cycle"]["pct_dropped"] >= 1]
km  = sum(x["km"] for x in cys)
pct = sum(x["pct_dropped"] for x in cys)
km_per_pct = km / pct

Long rides dominate, which is what you want from a range estimate.

Rule 3: flag holes instead of hiding them

Polling fails. The phone is off, the server restarts, the scooter goes to sleep. If two readings are more than 40 minutes apart, the session between them is marked partial and the interface says so, rather than quietly presenting a duration or an "added percent" it cannot support. The same idea applies to trips: a ride seen only across a long gap is kept but flagged approx, and no average speed is claimed for it, because the time window is only a bracket.

Rule 4: say what the forecast reserves

The "is today's charge enough?" answer uses the current percent minus a fixed reserve (10 %), times the km-per-percent figure. Keeping the reserve as a named constant in the response means the number can be explained rather than argued with.

What this does not do

It only knows what the scooter reports, and readings can lag by a few minutes. It is not a theft or emergency tool and it does not control the scooter. It is a notebook.

If you build something similar for another vehicle, the transferable parts are the dedupe key, the minimum-signal thresholds, sum-then-divide, and explicit "partial" flags. The app is on Google Play if you want to see the output.

Four fields of a UPI QR worth reading before you hand it off, and the edge cases in each

Ashwar Sadh — Fri, 30 Oct 2026 06:16:43 +0000

A UPI QR decodes to a short link, upi://pay?pa=...&pn=..., and an app that reads QR codes can hand that link straight to a UPI app. Before it does, it is worth reading a few of the fields and showing them to the user, because that is the moment they can still notice something is wrong. This post goes through the four fields Auto UPI QR reads (pa, pn, am, mc), the odd values each one turns up in real QRs, and how the parser treats them.

The confirmation sheet described here is in the next version of Auto UPI QR, not in the build on Google Play today.

Disclosure: I'm the developer of Auto UPI QR, and this post is published from my account. It was written and published by an AI agent working on my behalf. Auto UPI QR only reads QR codes; the payment happens in your own UPI app. Always check the payee name before entering your UPI PIN.

Read, don't rebuild

One rule first. The app reads these fields for display only. What it hands to the UPI app is the original link, with nothing re-encoded: merchant QRs can carry signed fields (tr, mode, orgid, sign and others) that must arrive exactly as printed. So the parser is a small read-only view over the original text:

data class UpiQr(val raw: String) {
    private val uri: Uri = Uri.parse(raw)

    private fun param(name: String): String? =
        try { uri.getQueryParameter(name)?.trim() } catch (e: Exception) { null }
}

getQueryParameter decodes percent-escapes (so pn=Shop%20Name reads as Shop Name) and throws on some malformed inputs; the try turns those into "field missing" rather than a crash on a bad sticker.

`pa`: the only required field

pa is the payee's UPI ID, the one thing the payment actually goes to. A link without it is not something a UPI app can pay, so the parser rejects it outright instead of showing a half-empty sheet:

fun parse(text: String?): UpiQr? {
    if (text == null) return null
    val m = PREFIX.find(text) ?: return null          // ^\s*upi://pay, any case
    val normalised = "upi://pay" + text.substring(m.range.last + 1).trimEnd()
    val qr = UpiQr(normalised)
    return if (qr.payeeVpa.isNullOrBlank()) null else qr
}

The prefix match also tolerates leading spaces and an upper-case UPI://PAY, which some printed stickers use (Android matches intent schemes case-sensitively, so the scheme is lower-cased; everything after it is kept as is).

`pn`: a claim, not a fact

pn is the name printed into the QR by whoever made it. It is often missing on personal QRs, and nothing stops anyone putting any name there. Two consequences:

If it is missing or blank, say so in words ("Payee name not in QR") rather than leaving a gap the eye skips over.
Never present it as verified. The name that counts is the one the UPI app shows after it looks up the UPI ID. That is why the app repeats one line everywhere: always check the payee name before entering your UPI PIN.

`am`: zero means "no amount"

A QR can fix the amount, or leave it to the payer. Real QRs express "no amount" in more than one way: no am at all, am= with nothing after it, or am=0 / am=0.00. Treat all of them the same:

val amount: String? get() = param("am")?.takeIf { it.isNotBlank() && it.toDoubleOrNull() != 0.0 }

Only a real amount is shown, as written in the QR. Showing "₹0.00" on the sheet would suggest something the UPI app won't do, which is pay zero.

`mc`: the field that predicts trouble

mc is the merchant category code. Shop QRs issued through a payment provider carry a real code; personal QRs carry the placeholder 0000 or nothing. The parser reduces that to one flag:

val isMerchant: Boolean get() = param("mc")?.let { it.isNotBlank() && it != "0000" } ?: false

The flag matters because of what happens next. UPI apps often refuse a QR without a merchant code when it is opened from another app, and they may only say so after the PIN is entered. So when isMerchant is false, the sheet says it up front: this QR has no shop code, the UPI app may refuse it, and if it does, there is a one-tap way to pay by UPI ID instead. A warning before the PIN beats an error after it.

Finding the link in a message

Sometimes the link arrives as text in a chat rather than as a QR image. The app looks for the first upi://pay? link in the text and runs it through the same parse, so the same rules apply wherever the link came from:

fun findIn(text: String?): UpiQr? {
    if (text == null) return null
    val m = Regex("upi://pay\\?\\S+", RegexOption.IGNORE_CASE).find(text) ?: return null
    return parse(m.value)
}

Takeaways

Parse for display; hand off the original text. Never rebuild a payment link from parsed fields.
Reject links without pa before showing anything.
Treat pn as a claim. Say when it is missing, and never call it verified.
Normalise "no amount": absent, blank and zero are the same thing.
Use mc to warn before the PIN, not to explain after it.
Wrap getQueryParameter so a bad sticker becomes "field missing", not a crash.

Auto UPI QR is on Google Play: https://play.google.com/store/apps/details?id=com.ashwar.autoupiqr. It reads UPI QR codes from images and hands them to your own UPI app; it is not a bank and never sees your PIN. The confirmation sheet described here is in the next version, not on Play yet. Always check the payee name before entering your UPI PIN.

Power saving switched my accessibility service off. When is an app allowed to switch it back on?

Ashwar Sadh — Fri, 30 Oct 2026 06:13:59 +0000

On several Android phones, ultra or maximum power saving mode turns every accessibility service off, and leaves them off when power saving ends. For an app built around an accessibility service, that looks to the user like the app silently stopped working. This post is about how QuickDial handles that: when it may turn its own service back on, when it must only ask, and the one rule that decides between them.

The two ways a service goes off

QuickDial's chat helper is an accessibility service: it reads the open chat's title so the app can put a call button on screen. It can go off for two very different reasons:

The system turned it off. Power saving mode switched it off along with every other service.
The user turned it off. On purpose, perhaps because another app (a banking app is the usual case) refuses to run while an accessibility service is on.

The second case has to be respected absolutely. An app that turns its service back on after the user switched it off is overriding the user, and on a phone that runs a banking app it would also break that app. So "turn it back on" is never a default. It is something the app may do only when it can tell the first case from the second.

Can an app turn it on at all?

Normally, no. The enabled services live in the secure setting ENABLED_ACCESSIBILITY_SERVICES, and writing it needs WRITE_SECURE_SETTINGS, which no runtime dialog grants. It can only be granted from a computer:

adb shell pm grant com.ashwar.quickdialbridge android.permission.WRITE_SECURE_SETTINGS

That makes automatic restore an option for managed phones (an office fleet set up once over adb), not for ordinary installs. Everyone else gets a notification and a button. Both paths go through the same decision.

Record the cause when you see it go off

The decision needs to know why the service went off, and the only moment you can tell is when it happens. QuickDial watches the secure setting with a ContentObserver and also records when power saving last changed. When it sees the service go from on to off, it classifies the cause:

enum class OffCause { USER, POWER_SAVE, UNOBSERVED }

const val POWER_SAVE_WINDOW_MS = 2 * 60 * 1000L

fun causeSeenTurningOff(powerSaveOn: Boolean, msSincePowerSaveChange: Long): OffCause =
    if (powerSaveOn || msSincePowerSaveChange in 0..POWER_SAVE_WINDOW_MS) {
        OffCause.POWER_SAVE
    } else {
        OffCause.USER
    }

The two-minute window covers the ordering problem: the service can be switched off a moment before or after the power-save broadcast arrives.

There is a third case. Power saving often kills the app too, so the service may go off while nothing was running to see it. Next time the app runs (at boot, after an update, when the user opens it, when a listener reconnects) it finds the service off with no recorded cause, and stores UNOBSERVED. That one is treated like power saving, because a user who switches the service off in Settings while the app is alive is seen doing it; the unseen case is almost always the system.

The rule, as one pure function

fun shouldAutoRestore(
    canWriteSecureSettings: Boolean,
    wasEverEnabled: Boolean,
    cause: OffCause,
    powerSaveOnNow: Boolean,
): Boolean = canWriteSecureSettings && wasEverEnabled && cause != OffCause.USER && !powerSaveOnNow

Every condition is there for a reason:

cause != USER: never undo the user's own choice.
!powerSaveOnNow: restoring inside power saving gets undone at once, so wait until it ends. The power-save broadcast is one of the triggers, so the check runs again when it does.
wasEverEnabled: if the user never set the service up, that is an onboarding problem, not a restore.
canWriteSecureSettings: without the adb grant, fall through to asking.

Keeping this as a plain function means a JVM unit test can walk all the combinations without a device.

Append, never replace

ENABLED_ACCESSIBILITY_SERVICES is one colon-separated string shared by every accessibility app on the phone. Writing just your own component into it switches everyone else's off. Append instead, and do nothing if you are already listed:

fun withService(existing: String?, component: String): String {
    val parts = existing.orEmpty().split(':').map(String::trim).filter(String::isNotEmpty)
    if (parts.any { it.equals(component, ignoreCase = true) }) return parts.joinToString(":")
    return (parts + component).joinToString(":")
}

Then set ACCESSIBILITY_ENABLED to 1, and read the state back to confirm it worked before treating the restore as done. A restore attempt is also rate-limited (once a minute), so several triggers firing together don't hammer the setting.

When you can't restore, say what is paused

Without the grant, or when the user turned it off, the app posts one ongoing notification with a fixed id, so repeat checks update it silently instead of stacking. It says what is paused, what still works, and has a button that opens the setting. When the cause was power saving and the app is not exempt from battery optimisation, it adds a second button for that, since the exemption helps keep the app running so it can notice and act when power saving ends. If the user swipes the notification away, it stays away for six hours; the same message is still shown as a banner inside the app.

No polling

None of this runs on a timer. The checks hang off events the app gets anyway: the secure-setting observer, power saving turning on or off, the notification listener reconnecting, BOOT_COMPLETED, MY_PACKAGE_REPLACED, and the app being opened. An app trying to survive power saving should not be the reason the battery drains.

Takeaways

A service the user switched off stays off. Build the restore path around that rule, not the other way round.
Record why it went off at the moment it happens; afterwards you can only guess.
Treat "went off while the app wasn't running" as the system, not the user.
Don't restore while power saving is still on; wait for it to end.
The enabled-services setting is shared. Append to it, never overwrite it.
Without the adb-only grant, ask clearly, once, and say what still works.

QuickDial is on Google Play as "QuickDial: Direct Chat & Call": https://play.google.com/store/apps/details?id=com.ashwar.quickdialbridge. It works with WhatsApp and WhatsApp Business; independent app, not affiliated with WhatsApp LLC or Meta.

DEV Community: Ashwar Sadh

Same audio, four request IDs: keying idempotency on the bytes so a phone can resend safely

Problem 1: an idempotency key that never matched

Key on what the work is, not on what the client calls it

The store: share the promise, cache only success

Problem 2: giving up on a link that was only flaky

A read timeout that scales with the note

Takeaways

A button on the lock screen must not open a chat: an unlock trampoline on Android

The risk

Decide at the call site

The trampoline

The manifest entry matters as much as the code

Reading the wrapped intent

Version notes

Test it like an attacker would

Takeaways

Binding to 127.0.0.1 is not enough: keeping a local control API away from the web pages in your own browser

What loopback does not stop

What the legitimate callers look like

The guard

The edge cases the tests pin down

Two cheap extras on the dashboard

What this does not cover

Polling someone else's API politely: an interval that follows the vehicle's state, a per-user floor and one global token bucket

1. The interval follows what the vehicle is doing

2. Keep watching after the data goes quiet

3. A hard floor per user

4. One token bucket for the whole service

5. Stop on the first "no", and keep a kill switch

What it costs

A heartbeat that goes quiet when the route is dead: signed presence records with a short TTL

1. Sign the record, don't trust the transport

2. Short TTL, steady heartbeat

3. Publish only while the route works

4. Say who said no

Takeaways

A share-target Activity that must not run twice: why it finishes itself when Android restores it

The restore problem

One line

The rest is dispatch by what was shared

The Parcelable API split

Scanning off the main thread

Takeaways

The caller's number was a timestamp: picking a phone number out of an Android call notification

How the app sees a call

The 13 digits

Rule 1: a recent epoch time is never a number

Rule 2: a direct number must be valid for its numbering plan

Rule 3: junk is not an identity either

Keep it pure, keep the defect in the comment

Takeaways

The desktop app you scrape updated overnight: a version watch that re-checks what you depend on, once per change

The failure that started it

Step 1: know the installed versions without asking the app

Step 2: the live check names problems in plain sentences

Step 3: separate problems from notes

Step 4: run on change, not on a schedule

Step 5: don't blame the update for a restart

What the message looks like

Takeaways

Check for updates always, restart only when nobody is typing: an idle gate for a self-updating Node.js helper

The first rule was too cautious

Split the decision in two

The gate itself

One waiter at a time

What I'd keep from this

Real range from a scooter's battery readings: sum the kilometres, sum the percent, then divide

The raw material

Rule 1: do not divide tiny numbers

Rule 2: sum first, divide once

Rule 3: flag holes instead of hiding them

Rule 4: say what the forecast reserves

What this does not do

Four fields of a UPI QR worth reading before you hand it off, and the edge cases in each

Read, don't rebuild

pa: the only required field

pn: a claim, not a fact

am: zero means "no amount"

mc: the field that predicts trouble

`pa`: the only required field

`pn`: a claim, not a fact

`am`: zero means "no amount"

`mc`: the field that predicts trouble