My phone is a Light Phone III. It has no Oura app, and it never will.

So I wrote one — most of one — and then hit a wall I still haven’t gotten past, in a place I didn’t expect. This is the writeup, because the failure turned out to be more interesting than the feature.

The protocol was the easy part

I assumed the reverse engineering would be the hard bit. It wasn’t, because Th0rgal already did it, pulling the protocol out of the official Android app’s native libraries and checking it against a Ring 3 and a Ring 5. The ring’s authentication is much smaller than its reputation:

get nonce       2f 01 2b            → 2f 10 2c <15-byte nonce>
authenticate    2f 11 2d <16 bytes> → 2f 02 2e 00   accepted

The ring holds a 16-byte key. Every connection it hands you a 15-byte nonce, you encrypt the nonce with the key, and you hand back the 16 bytes. That’s it. No key exchange, no certificate, no server. Two published descriptions of this float around and look different — “encrypt the nonce with PKCS5 padding” and “AES-128-ECB over the nonce plus a 0x01 byte” — and they’re the same operation, because PKCS#5 pads a 15-byte input with exactly one 0x01.

A week of evenings got me a scanner, a probe that reads firmware and serial without authenticating, a key installer, a history drain, and decoders for heart rate variability, inter-beat intervals, temperature and steps. Forty unit tests. The decoders have no Android imports at all, so I can run them against bytes I typed by hand instead of against a ring that produces one night per night.

Then I tried it on the phone.

Everything interesting is behind an encrypted link

Firmware and serial answer cold. Battery, history and the live streams answer 2f 02 2f 01 until the session authenticates. To authenticate you subscribe to a characteristic, subscribing is the first operation on the link that needs encryption, and encryption on Bluetooth means the phone and the ring have to be bonded.

A bond needs somebody to say yes.

Here’s what Android does with that. The pairing request goes out as a notification carrying a full-screen intent, and the platform expects the launcher to raise the dialog sitting behind it. LightOS doesn’t raise it. The phone chimes, nothing appears, the request expires in under a minute, and the bond fails with every layer working exactly as designed.

Fine, I thought. The dialog is an ordinary activity. I’ll start it myself.

It’s com.android.settings/.bluetooth.BluetoothPairingDialog, and on this phone that fragment builds a null dialog and dies with a NullPointerException in DialogFragment.prepareDialog. Not a permission problem, not my code. The screen that exists to accept a pairing request crashes when you ask it to accept a pairing request.

Nine routes

The whole search, in the order I tried it. Each one exists because the one above it failed.

1. Wait for the prompt. No prompt is drawn, and most BLE bonds have no dialog at all, so I was waiting on an event that doesn’t happen.
2. Answer the request myself with setPairingConfirmation(true). It throws. The call wants BLUETOOTH_PRIVILEGED, which is signature-level and can’t be granted over adb.
3. Start the Settings dialog directly. That’s the crash above.
4. Pair by hand in Settings. AOSP Settings crashes on the pairing screen. LightOS has its own Bluetooth screen, which pairs earbuds happily, and it says “pairing” and then stops.
5. Press the notification’s Pair button from a listener service. A notification action runs as the app that created it, so this needs no permission at all, and I liked this one. The button starts the activity from step 3.
6. pm clear com.android.settings, in case a crashing Settings never posted the request in the first place. Reversible, worth ruling out, changed nothing.
7. The companion device flow. CompanionDeviceManager is a different shape: the app asks, the system runs a device picker, and the picker comes back as an intent the app launches itself — an activity, on a phone that draws no notifications. The platform even skips the consent dialog when the bond is requested by an app holding a fresh association for the same address. Two surprises there: createBond records no caller when a bond is already in flight, and the watch profile bonds from the system at association time, which makes your own call a no-op with nobody on file.
8. Ask with the screen off. This one is real. BluetoothPairingRequest only starts the dialog activity while the phone is interactive, and asleep it posts the notification instead. Which is step 5.
9. Give up on the phone’s UI entirely.

The shell holds the permission

com.android.shell has BLUETOOTH_PRIVILEGED, granted and privileged, along with BLUETOOTH_STACK. The adb shell is the one process on this phone that can answer a pairing request with no interface whatsoever, and I already have an app that holds an adb shell over wireless debugging, because I wrote one.

So the pairing helper is a plain main class living inside my own APK, which is world-readable, run through that shell:

CLASSPATH=/data/app/…/base.apk app_process / com.gios.brightoura.helper.Confirm <MAC>

It asks for the bond and answers the request it raised, in one loop, as one uid. Getting a working Bluetooth adapter inside a bare app_process took four discoveries, and not one of them throws when it’s missing:

• Bluetooth is a mainline module since Android 13, and its service wrapper is registered during application startup. A plain main class is not an application, so getDefaultAdapter() politely returns null. You construct and install the service manager yourself.
• The adapter’s binder arrives on a callback posted to the main looper. Prepare the looper and never run it, and every bond operation returns false and says nothing.
• AdapterService.createBond checks your package name against your uid, so the adapter needs an attribution source claiming uid 2000 and com.android.shell.
• Exactly one construction route lets you set that attribution source.

Four evenings. Then this came back:

createAdapter(shell): ok
attributed to com.android.shell (uid 2000) via createAdapter
createBond true
state BONDING
setPairingConfirmation true
waiting… 51s left, state BONDING
…
state NONE
RESULT refused after confirming

Read it from the top. The adapter works. The bond starts. The confirmation goes through. The two ends exchange keys for twenty-seven seconds. Then the bond falls apart, and my own helper reports the least useful sentence available to it.

I never asked why

ACTION_BOND_STATE_CHANGED carries EXTRA_REASON — a number that says whether the keys mismatched, the ring rejected the phone, the ring went out of range, the exchange timed out, or the stack is refusing because too many pairings have failed recently. My helper had never once asked for it. It read the state afterward, found a bare NONE, and printed “refused after confirming,” which is an honest answer to the wrong question.

I have a strong suspicion about which reason it is, and there’s no drama in it at all: after a dozen failed attempts in an evening, the Bluetooth stack starts refusing on a counter, and the remedy is to turn Bluetooth off and on and wait a minute. If that’s what it says, then every attempt in the most interesting session of the week was being judged by a timer rather than on its merits.

That’s where the project is parked. The version that prints the reason is built and shipped and I haven’t run it yet, which says more about how projects go than about Bluetooth.

What the failure was worth

Three things came out of it that the success wouldn’t have produced.

A Ring 4 Bluetooth table nobody appears to have published. The protocol notes describe two characteristics. My ring has five, plus a second service nobody has written about, and one of the undocumented ones reads and writes and notifies — which is what a request/response channel looks like when it doesn’t want a subscription. If that channel answers, the whole bonding wall becomes irrelevant, and writing one request to it is the cheapest thing left to try.

A decoder that can be corrected. Every frame the ring gives up is stored as raw bytes, decoded or not, because the ring’s buffer is finite and what it hands over once it won’t hand over twice. The temperature and step layouts are inferred rather than documented, and the code says so on every reading it produces. The first real night of data gets to correct them, instead of quietly confirming a scaling error.

A rule I keep relearning. LightOS is Android with pieces of the user-facing platform absent, and the absences don’t announce themselves. The same week as all this, every one of my Light SDK tools with a text field in it started crashing on a phone update, because the reply to “what should the keyboard look like” gained a field and lost a field, and decoding that reply was the one step in the call nobody had guarded. A screen that only wanted to draw a keyboard took the whole process down with it.

Both failures have the same shape: the contract with the platform moves, and the code finds out in the least helpful way available. The habit that pays isn’t defensive coding in the abstract. It’s making the failure legible at the moment it happens, and keeping the bytes. Two saved transcripts are the only reason this story has a next step.

If you want to take it further

Everything is in BrightOura, MIT, and the handoff document is the real artifact: what works, all nine routes with the mechanical reason each one is closed, the framework discoveries, the transcripts, and six ranked next steps written as what each would prove. Two of them can end the project honestly, which is worth more than a tenth route.

If you have a Ring 4 and a phone whose Settings app doesn’t crash, you can settle in an afternoon what I couldn’t settle in a week.

It’s Android 14, and that’s a feature

LightOS is Android 14 underneath, with a locked bootloader. No jailbreak, no unlock, no exotic toolchain — adb install works the way it works everywhere, and ordinary modern APKs run. The entire community app scene exists because Light left this door open, and I choose to believe it’s open on purpose.

What’s removed matters more than what’s changed, and the removals fail in a very particular way: the API stays, and answers nothing. There are no Google services, and Android’s plumbing quietly assumes there will be. Some examples I’ve personally lost time to:

• android.speech.SpeechRecognizer exists, but there’s no provider to bind to. android.speech.tts exists, but no engine is installed. A voice assistant on this phone has to send both directions to the cloud — that’s why LightVoice is built around Whisper and a TTS API rather than anything on-device.
• SpellCheckerSession accepts your requests and corrections silently never arrive, because nothing is installed to answer them. LightKeyboard bundles its own 63k-word dictionary and a bigram table because that’s the only spell-check that will ever exist here.
• There’s no push messaging. Anything that needs to be told something has to bring its own transport, which is why my iMessage client talks to a self-hosted server over Tailscale.

The pattern is worth internalizing before you build anything: on LightOS, a dead API doesn’t error. It just never calls you back.

The hardware talks in key events

This is the finding that unlocked the most, so it gets the most space. The wheel, the camera button, and the home button all arrive at whichever app has focus as ordinary KeyEvents. Light patched /system/usr/keylayout/Generic.kl — the keylayout every input device on the phone loads — and you can read the whole story in five lines:

key 19    WHEEL_CCW      # wheel up       (Pixart pat9126ja, was R)
key 20    WHEEL_CW       # wheel down     (Pixart pat9126ja, was T)
key 66    WHEEL_CLICK    # wheel press    (gpio-keys, was F8)
key 80    FOCUS          # camera stage 1 (was NUMPAD_2)
key 27    CAMERA         # camera stage 2 (was RIGHT_BRACKET)

Things I now know that I wish someone had told me:

• The wheel is a mouse part, not a rotary encoder. It’s a Pixart pat9126ja optical sensor firing one discrete DOWN+UP key pair per notch, roughly 35–60 ms apart. Android’s actual rotary plumbing — AXIS_SCROLL, onRotaryScrollEvent — never sees a thing. Anything wheel-aware has to be built on raw key events, counting notches yourself.
• WHEEL_CCW, WHEEL_CW and WHEEL_CLICK aren’t AOSP keycodes. They’re Light’s labels, and you resolve them by name at runtime. Hardcode the numeric codes and you’re betting against a firmware update.
• The camera button is two-stage, like a real shutter: half-press sends FOCUS, full press sends CAMERA. Two keys, two gestures, and the stock camera’s behavior stops being magic.
• Nothing intercepts any of this in PhoneWindowManager. The brightness ramp and flashlight in Light’s own tools are app-layer code in those tools. In your sideloaded app the keys arrive and nothing listens, which feels like a missing API and is actually an invitation.

The only sanctioned way to hear these keys globally — without having window focus — is an AccessibilityService with flagRequestFilterKeyEvents; the injection route (INJECT_EVENTS) is signature-only and closed to you. That’s what BrightControl is. One design note I’d urge on anyone building similar: declare canRetrieveWindowContent="false" and subscribe to the minimum event types you can. An accessibility service asks for real trust, and the manifest is where you make the limits checkable rather than promised.

Notifications are boringly standard, and that’s a gift

LightOS posts fully standard Android notifications, so NotificationListenerService just works — that’s the entire basis of LightGlance, which draws ambient notification dots on the black panel. No parsing of Light’s internals, no package allowlist, just the platform doing what the documentation says.

The catch is granting the permission: LightOS has no Settings screen for notification access, so the grant is adb-only —

adb shell cmd notification allow_listener <component>

— and this generalizes. A recurring LightOS pattern is that the capability exists but its Settings UI doesn’t, so runtime permissions that would normally show a dialog get granted with pm grant, appops with appops set. The grants survive reboots. Every one of my READMEs with a permissions section is really documenting this same gap.

While I’m here: there is no reachable always-on display. A real AOD is a low-power panel self-refresh mode owned by SystemUI and the panel driver, and a sideloaded app cannot touch it on any Android. If you see “AOD” on a sideloaded LightOS app, it’s the screen genuinely on at minimum brightness, and the honest budget for that is 2–4%/hr. Glance’s default is to wake for eight seconds when something arrives, because that costs approximately nothing and does most of the job.

Networking has one big footgun

Join a Wi-Fi network that has no internet — a camera’s access point, say — and Android keeps routing your traffic over LTE. Every socket you open goes to the wrong network, and it presents as a device that pairs happily and then refuses to talk. The fix is WifiNetworkSpecifier to join plus bindProcessToNetwork to pin your sockets, and as a bonus the specifier path means the system shows the network picker, your app never sees a scan result, and you don’t need the location permission every other camera app demands. BrightImport is built on exactly this, and its CI fails the build if a location permission ever sneaks into the manifest.

Bluetooth: BLE yes, L2CAP no

Standard BLE scanning works fine — LightPods reads AirPods battery levels straight out of Apple’s proximity advertisements with nothing but BLUETOOTH_SCAN. But the richer channel (AAP over L2CAP, where noise control and real ear detection live) is walled off three ways: Android didn’t allow third-party L2CAP sockets on this codebase until a fix that landed in Android 16, the LP3 is Android 14, and the bootloader is locked so the usual workaround can’t install. Knowing which wall you’re behind saves you from debugging the wrong one.

The panel sets the rules

Everything renders grayscale, and designing for it is closer to print than to normal app work. Contrast does the work color would. Patterns replace palettes — when I needed tape labels to be distinguishable in the recorder, the answer was geometry, not hue. Type carries almost everything, and LightOS’s own type and spacing conventions are consistent enough that matching them makes an app feel native with no other effort.

The conventions nobody voted on

The community converged on packaging norms the way small scenes do — quietly, by copying each other. One APK per GitHub release. Tags ending in a number. A stable signing key per app so upgrades install in place; I go one further and pin the certificate’s SHA-256 in the repo with CI failing on drift, because a changed certificate otherwise surfaces only as Failure: Invalid on someone’s phone. My update tracking and the app index lean on all of these, and none of them are written down anywhere official. They’re just what works, repeated until they became load-bearing.

That’s the phone as I currently understand it. Nothing here is a discovery — it’s all sitting in system files, AOSP sources, and other people’s repos. But small platforms live or die on whether the folklore gets written down, and this is me writing mine down.

Tapes, not files

Record a moment and it becomes a clip named for where you were and when. Clips live on tapes, and you keep more than one — a tape for a trip, a tape for the apartment, a tape for the year. The machine holds exactly one tape at a time, and you swipe through the rest on a shelf. Each tape gets a name and a pattern on its label, which is what color would be if this panel had any.

Under the hood a tape is a directory of WAV files and nothing more. The clip’s timestamp and place are the filename. Rename the folder, you’ve renamed the tape. Plug the phone into a desktop and the whole collection reads as itself — no database, no export step, no app required to get your own recordings back. I keep coming back to that rule in these apps: the storage format should make the app optional.

The wheel finally has its job

The part I’m happiest with: winding. Turn the brightness wheel and you wind through a tape, forwards or backwards, and you hear it while you wind, the way a real tape machine chatters while you scrub. Let go and it plays from where you landed.

I’ve put the wheel to work in most of my apps — scrolling, lens ring, brightness — but this is the first time it’s felt less like an adaptation and more like the thing the hardware was born for. A physical wheel wants to shuttle tape. It’s been waiting for this job since the phone shipped.

None of this is a new idea. It’s the oldest audio interface there is, drawn in software. That’s the whole appeal — a tape recorder was already a nearly perfect object, and the only modern thing this phone needed to add was the filename.

Let me at least explain how I got here. The launch post covers what shipped and how to get your own app listed. This is the other half: why it exists at all, what’s holding it up, and the afternoon I broke it.

The problem was never installing apps

Sideloading works fine on this phone. LightOS is Android underneath, and an APK installs the way an APK installs anywhere. The problem is what happens three weeks later, when you have fifteen sideloaded apps and every one of them updates on its own schedule, on its own GitHub release page, and nothing on the phone knows any of that.

Obtainium solves this, and solves it well. I used it for months. But it’s built for a normal Android phone, and it only knows about the repos you paste into it yourself. There was no answer to the more basic question: how does anyone find out these apps exist at all? For a while the honest answer was “a Reddit thread and word of mouth.”

So BrightMarket does the same update tracking Obtainium does, fits this phone, and adds a catalog on top. Find an app, install it, get told when it needs updating. That’s the whole product.

The uncomfortable part

An app store on a minimalist phone is still an infinite scrolling feed. I couldn’t design my way out of that, so I stopped trying and made browsing optional instead. On first launch the app asks. With Focus mode on, it shows what you have installed and what needs updating, and nothing else. No catalog, no feed, no discovery. A surprising number of people pick that mode, which I choose to read as the userbase keeping me honest.

No server, on principle and also on budget

There is no backend. The “database” is a public GitHub repo: one YAML file per app, and a CI job that rebuilds a single JSON index every hour and serves it from GitHub Pages. Submissions arrive as pull requests against that repo, which means the whole catalog has a public history — you can read every app that was ever added, by whom, and when.

Download counts come from GitHub’s own release statistics, so the “most downloaded” sort costs nothing and tracks nobody. The app never phones home. I couldn’t run analytics if I wanted to, which is the correct amount of temptation to have.

The part where I got it wrong

One afternoon in August, the GitHub Releases API started returning empty lists. Not errors — clean HTTP 200 responses with nothing in them. My builder read “no releases” and helpfully dropped those apps from the index. Other people’s apps, gone from the catalog, because of my code and someone else’s outage.

An HTTP error had always kept the previous entry. A successful empty response didn’t, because I’d never imagined one. The rule that came out of it is now written into the repo: an app is never dropped for an answer the API failed to give.

Somewhere along the way this thing became how most Light Phone III owners install community apps. I didn’t plan for that and I try not to think about it too hard. Mostly it means the bar for “good enough” moved, and the empty-response bug is what taught me where it moved to.

Which is fine — that’s what open source is for. But forking has an etiquette, I’ve been on both ends of it now, and I have opinions.

Keep their README

When I forked Craig’s chat app, his README didn’t get rewritten — it got moved to the bottom of mine, preserved as he wrote it, under his name. The top of the file says plainly: Craig wrote the app; here’s what this fork adds; nothing here is upstream’s responsibility. That last part matters more than the credit. The worst thing a fork can do to its upstream isn’t stealing glory, it’s leaking bug reports. If my Favorites tab breaks, that issue belongs on my repo, and the README’s job is to make sure it lands there and not in Craig’s inbox.

Never touch the applicationId

This one’s technical and absolute. On Android, the applicationId is the app’s identity. Change it and you haven’t renamed the app — you’ve created a second app that installs alongside the first, and every user’s data stays trapped in the old one. Several of my apps still carry light* package names from before a rename, and they always will. The name on the screen is free to change. The identity underneath is not, and no amount of tidiness justifies breaking it. This rule is written into the BrightMarket index with a comment that says, roughly, do not “fix” this.

Renaming is not rebranding

The Bright* names exist so the collection reads as a collection — so someone who liked one app can find the others, and so update tracking has a consistent home. The rename is packaging, not authorship. If the name change ever starts implying the work is mine when it isn’t, the README exists to un-imply it, loudly and first.

Send things back when they fit

Not everything I add belongs upstream — a Favorites tab tuned to this phone’s wheel probably doesn’t help a general-purpose app. But when a fix is general, it should travel. The fork relationship shouldn’t be a one-way valve.

I don’t think any of this is original wisdom either. It’s mostly what the licenses already ask, plus some manners. But small communities run on the assumption that building on someone’s work is a compliment and not a raid, and that assumption survives exactly as long as forks keep saying where they came from.

I built this because the alternative was worse. Bug reports for phone apps normally arrive as a Reddit comment three weeks later: “the camera thing broke.” Which screen? Which version? Gone. The reporter has moved on, and honestly, fair — describing a bug is work, and nobody owes me work. So the app does the describing. The person just shakes.

The 360-pixel witness

The screenshots come through grayscale and 360 pixels wide, and I expected them to be useless. They’re the most valuable part of the report. A broken layout, a stuck spinner, a date that’s obviously wrong — you can see it instantly, in a way no prose description gets close to. Most reports are diagnosable from the screenshot and the build table alone.

Then I stopped being the bottleneck

The reports land in one repo, and for a while “triage the queue” was a thing I did with coffee. Now an AI agent does the first pass, every hour. It reads each new report, clones the app’s source fresh, and works out what happened.

The rules I gave it are mostly rules about restraint:

• Fix it only when the cause is identified — a stack trace naming the line, code that visibly does the wrong thing — and the fix is small and contained. A null guard. An off-by-one. A missing state reset.
• Hand it to me when the cause is a guess, when the fix would change behavior someone might have an opinion about, when it needs the physical phone, or when it touches more than about three files.
• Never reuse a stale checkout, because pushing from an old base silently deletes whatever landed in between, and it compiles perfectly afterward.
• Branch first, always. In these repos a push to main cuts a signed APK that’s on people’s phones within minutes, with no human between a mistake and the device. CI runs the same checks on a branch and publishes nothing.

The line I keep coming back to when tuning it: guessing is worse than waiting. A wrong fix ships. A waiting issue just waits.

Does it work?

For the boring majority of reports — yes, and the boring majority is the point. Null guards and layout constraints get diagnosed, fixed, tested, and released while I’m at work, and the release notes say what changed. The interesting bugs, the ones where the report is really a design question wearing a trench coat, get labeled and handed to me with the agent’s notes attached. That split is the whole value: I only see the reports that actually need a human, and the person who shook their phone gets a fix in hours instead of whenever I next had a free evening.

The plumbing that makes this possible in every app at once — the shake detector, the report overlay, the crash handler — lives in a shared library, which is its own unglamorous story for another post.

At some point I looked up and had a lot of Light Phone apps. Every one of them needs the same plumbing: handle the hardware keys, drive the scroll wheel, draw text in the phone’s type and color system, run the shake-to-report machinery. And every one of them had its own copy. LightKeys.kt was byte-identical in fifteen repos. The wheel handling existed in about ten variants across twenty — not because ten variants were needed, but because each copy drifted a little after it was pasted.

You can guess the failure mode. A fix to the wheel meant twenty edits, so the fix got made once, in whichever app I happened to be in, and the other nineteen kept the bug. Multiply by every shared component and the collection was slowly turning into an archaeology site where you could date each app by which bugs it still had.

The part that actually convinced me

Tidiness alone never gets me to do a refactor this dull. What did it was porting the report module into the older apps by hand — the same feature, wired into ten repos by pattern-matching against a reference implementation. Eight of the ten ended up subtly wrong. Not broken-wrong, CI-catches-it-eventually wrong. Same feature, ten bespoke wirings, eight quiet mistakes.

That’s not a tidiness problem, that’s a correctness problem. Copy-paste isn’t just harder to maintain; it’s a machine for manufacturing bugs that all look slightly different.

So the shared pieces moved into one library, published to GitHub Packages, and every app pulls it in as a dependency like anything else.

Small design notes from a small library

A couple of decisions I’d defend:

One call, no partial states. LightReport.install(...) sets up reporting and arms the crash handler. There’s no way to end up with an app where shake-to-report works but crash capture doesn’t, because there’s no second call to forget.

Inert by default. Skip the install call entirely and the whole feature is dead weight — the overlay renders nothing, nothing is queued. An app can adopt the library without adopting every feature in it.

The overlay is a sibling, not a wrapper. It draws in its own window, so it doesn’t care what layout it’s called from, and adopting it doesn’t mean restructuring your UI tree.

One honest annoyance for anyone tempted to do the same: GitHub Packages requires authentication even for public packages. There’s no anonymous read. Every consumer needs a token with read:packages, which for a hobby ecosystem is pure friction with no upside I can find.

None of this is novel. Shared libraries are the oldest idea in software, and “don’t repeat yourself” is on the first page of every book. But there’s a difference between knowing the advice and watching eight hand-ports go subtly wrong in one afternoon. Now a wheel fix is one edit and a version bump, and the apps stopped drifting apart. Boring work. Recommend it.

The browsing lives on the desktop. brightmarket.gzl.dev is a real catalog — read about a tool, decide if you want it, scan its code with the phone, and it opens in BrightMarket ready to install. Browsing on a big screen, installing on the small one.

The tracking lives on the phone. The other half watches GitHub releases and tells you when something’s out of date. It’ll track any repo that publishes APKs, including ones that have nothing to do with the catalog, so you give up nothing you already follow. And you don’t rebuild your setup by hand: import your Obtainium export and it takes the lot. Catalog apps become normal entries. Everything else is tracked exactly as it was.

The choice at first launch

The part I sweated most: a gallery on your phone is a scrollable feed, and a scrollable feed on a Light Phone kind of defeats the point. So the app asks, first thing. Keep browsing on the phone if you want it, or go extra light, and the phone only ever shows what you’ve installed and what needs updating. New apps arrive by scanning a code off the desktop. You can still patch something at 2 a.m. without finding a laptop. You just can’t wander.

The friction is asymmetric on purpose. Turning browsing on is one tap. Turning it back off means scanning a code from the desktop page. Falling off the wagon should be slightly harder than climbing back on. I wrote about why the app is built this way separately.

What’s in it

At launch: the twenty-odd apps I’ve built for my own phone plus my forks of community tools — a camera, an ebook reader, RSS and newsletter readers, a TOTP authenticator, live scores, subway times, an Apple TV remote, a notebook, a couple of games. All free, all open source.

Getting your own app in

If you’ve made something for the LPIII, add it. Open the submit page, sign in with GitHub, pick a repo of yours that has a release, done. The sign-in asks for read:user and nothing else: it can see which public repos you own and can’t write anywhere.

Everything after that is a script. It checks that the release has an APK attached, reads the applicationId out of the APK itself rather than trusting what the form told it, and opens a pull request. Once that lands, the next index build picks your app up and it shows in the catalog.

Two things worth knowing before you submit. The repo has to publish a real release with the APK attached, not just source. And the applicationId is what the update tracker keys on, so changing it later breaks the update path for everyone who already installed you.

Launch day, honestly

The best bug reports arrived within hours. Uninstalling wasn’t obvious enough — fixed. Adding a repo required making a QR code when typing a URL would do — added. This is the whole reason to ship: a week of real users beats a month of me squinting at my own UI. If Light eventually ships an official tools store, I genuinely hope it’s better than mine. Until then: brightmarket.gzl.dev/apk on the phone, and everything else installs from inside.

Twenty-two leagues, zero API keys

The part I’m actually pleased with is the data story. The app covers MLB, NFL, NBA, NHL, MLS, five European soccer leagues plus the two UEFA cups, FBS college football, four women’s leagues, four levels of minor league baseball, and Formula 1 — and there is no account, no API key, and nothing to paste in, ever. Four public JSON providers carry all of it:

ESPN’s site API does the heavy lifting: every major, the European soccer, college football, most of the women’s leagues, and F1. The lovely thing about it is that the scoreboard response shape is identical across team sports, so one parser covers everything. The unlovely thing is standings, which nest differently per league — the fix is to walk the response’s children tree recursively instead of indexing into it and hoping.

MLB StatsAPI covers the four minor league levels, selected by sportId (11 through 14 for Triple-A down to Single-A). ESPN publishes no minor-league scoreboard at all; this is the same feed MiLB.com itself runs on, which is as close to the source as you can stand.

HockeyTech/LeagueStat carries the PWHL, and the fourth provider fills the last gaps. College football needed one extra trick: ESPN’s feed returns roughly 750 schools, so the app filters it down to the ~140 FBS programs, because nobody following Alabama wants to scroll past every Division III scoreline to find them.

Boring on purpose

Under the hood this is the least clever app I ship, deliberately. Follows are a SharedPreferences string set. Caches are plain files. There’s no database, no Room, no annotation processing in the build at all — clone it and it compiles fast and dumb. After a year of building increasingly elaborate plumbing for the other apps, there was real pleasure in writing one where the complete persistence layer is “a set of strings.”

Notifications work the way everything works on a phone with no push services: the app checks the feeds itself on a schedule and posts ordinary local notifications when a followed team’s game changes state. No server of mine in the loop, nothing tracking what you follow. If the phone is off, you find out the score the way people did in 2004, which frankly suits this phone.

I posted the short version on Reddit. This is the long one.

A card is packaging

The thing to understand about a contactless card is that almost none of it is the card. Inside the plastic there are exactly two functional parts: a chip about the size of a grain of rice, and a loop of wire running around the card’s perimeter. The wire is the antenna, and it’s also the power supply — the card has no battery. The reader radiates a 13.56 MHz field; the loop harvests enough energy from it to wake the chip, and the same coupling carries the conversation. That’s the whole machine. The plastic is packaging, and packaging can go.

The acetone part

Transit cards are laminated PVC. Soak one in 100% acetone overnight — pure hardware-store acetone, not nail polish remover, which has oils in it — and the laminate gives up. The layers soften and peel, and what’s left is the chip with its antenna coil attached, looking like the card’s nervous system with the body dissolved away.

Overnight in the bowl. The laminate gives up in layers; the mag stripe goes first.

Handle it like a cobweb. The coil is fine wire, the bond between coil and chip is the weakest point, and there is no fixing it if it tears. It took me a few tries to end up with a working one. I don’t think the task is genuinely hard; I think I’m clumsy, and the difference matters because you should budget more than one card either way.

The install

The chip-and-coil goes in the battery compartment. Two things I learned at actual turnstiles, by failing at them:

The coil wants to be spread to the very edges of the cavity while staying a coil. Loop area is everything — the voltage the chip harvests scales with the area the field passes through, and a scrunched-up coil is a deaf one.

Orientation matters more than it has any right to. Chip black-side down reads most reliably for me. I can’t give you the physics for that one; I can give you the turnstile data.

An earlier build, taped in for testing — you can see the coil spread to the cavity’s edges. The one currently in my phone is working too consistently to risk opening up for a photo.

The part where the phone fights back

First full test: intermittent failures, maybe one read in three. The culprit is the phone itself. The LP3’s NFC front end is a coil too, sitting in the same few cubic centimeters, and even idle it detunes the space around it — two resonant loops that close together pull each other’s resonance off frequency, and a transit chip living on harvested power has no margin for that.

The fix is to shut the phone’s radio up:

adb shell svc nfc disable

and svc nfc enable to undo it. The setting survives reboots. With the phone’s NFC off, my read rate went to effectively always. I’m working on an app to make this toggle less of a ritual, because a hardware mod that requires adb for daily operation is only half done.

Living with it

This is the part that makes it practical rather than a stunt: OMNY lets you register a card on their website and attach auto-reload. So the card inside my phone refills itself, and the phone taps through turnstiles like it always should have. My card expires in 2033. When it does, I’ll do it again.

The obvious next question — someone asked it within an hour — is a credit card. It should work identically; it’s the same physics and mostly the same chips. I haven’t tried, for the boring reason that I can’t walk into my bank and ask for five test cards. If you try it, I want to hear how it went. And for the advanced class: one commenter re-wound a card’s antenna around the bare chip with a NanoVNA to verify the resonant frequency, and wears it as a ring. That’s real radio work. Mine is the lazy version, and I’m at peace with that.

Caveats, honestly

Do this to a card you can afford to kill, because your first one probably dies. Acetone wants ventilation and patience. The MTA would presumably rather you didn’t, so consider this documentation, not advice. And if the phone ever ships a real wallet, I’ll be first in line to dissolve nothing at all.