Repository navigation
Check dark mode, and light the app mark from the theme - #88
Merged
Merged
Conversation
Everything rendered or asserted so far ran against whatever the device happened to be set to, which is light - so values-night had never been looked at, despite being a full second palette. A configuration override reaches it without touching the device. The tile contrast assertion now covers the dark palette too. The app mark's side was the face colour at reduced alpha, which composites toward whatever is behind it: darker on a dark background and lighter on a light one. Light mode therefore had the extrusion reading as a highlight rather than a shadow, the opposite of the real icon. Light now takes an explicit lower tone for the side - onPrimaryFixed against the face's colorPrimary, tone 10 against tone 40, at 0.8 alpha to stop it going too heavy. Dark keeps the alpha approach, because there is no standard role a step below primary's tone 80 and alpha already gives the right relationship against a dark background. Measured: the side is darker than the face in the app palette, under wallpaper colours, and in dark. M3's fixed roles were tried first and cannot do this. primaryFixed is 1.23:1 on a light background and onPrimaryFixed is 1.09:1 on a dark one - stable across modes, and invisible in one of them. The geometry is scaled 1.5x out of the adaptive-icon safe zone. It was drawn for a launcher, where the mark occupies the middle 72dp of a 108dp canvas so the system can mask it; nothing masks it here, so that padding just rendered it two thirds the size of the icon it replaced. Sized at 92dp on the login screen, which is Shane's call rather than mine. Known limit for anyone revisiting: the mark cannot have the real icon's light mint face while it sits on a white surface. That works on the launcher because the tile behind it is dark navy. Giving it a tile here would solve it and was not attempted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
parawanderer
temporarily deployed
to
Android Build
August 16, 2026 08:56 — with 
GitHub Actions
Inactive
GitHub Actions
Inactive
parawanderer
temporarily deployed
to
Android Build
August 16, 2026 08:56 — with
GitHub Actions
Inactive
GitHub Actions
Inactive
parawanderer
added a commit
to ubrt/OpenTagViewer
that referenced
this pull request
Sep 3, 2026
The one case this app cannot handle: a tag that is with its owner, so it is not in the Offline Finding network and there is nothing on Apple's servers to fetch however far back anyone looks. Everything about it was scattered across two blog series, four papers, three GitHub threads and a FRIDA repository, and none of it says which parts are settled. **The finding worth the whole document** is stek29's, in FindMy.py parawanderer#88: the proof of concept everyone reaches for writes GATT to a characteristic that is not present on a real AirTag with its owner nearby, because it is the *unauthorised* sound command. Authorised ringing - the owner's own tag, sitting next to them - is a different protocol over L2CAP. Somebody starting from the obvious PoC would spend a week finding that out. That has a bearing on parawanderer#139, which plays a nearby accessory's sound over GATT, so it is said in the document rather than left to be noticed. Also collects: what a nearby tag actually broadcasts and how that differs from a separated one (primary key every 15 minutes, secondary key daily at 04:00); Adam Catley on the first six key bytes travelling as the BLE address; the WOOT'22 firmware work behind seemoo-lab/airtag and what its jailbreak requirement really is; and AirGuard, which malmeloo says already rings tags from Android - marked unverified, because that claim is the strongest lead here and it should not be taken on trust. Nothing was read out of rustpush, apple-private-apis or export-findmy, per the clean-room note in docs/findmy-export/README.md. stek29's public comments are quoted; his branches are not. Index row added per rule 10. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This branch was previously deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Everything rendered or asserted so far ran against whatever the device happened to be set to,
which is light — so
values-nighthad never actually been looked at, despite being a full secondpalette. A configuration override reaches it without touching the device or restarting anything.
The tile contrast assertion now covers the dark palette too, not just the app and wallpaper ones.
The app mark's side was lit from the wrong direction
It was the face colour at reduced alpha, which composites toward whatever is behind it: darker on
a dark background, lighter on a light one. So light mode had the extrusion reading as a
highlight rather than a shadow — the opposite of the real icon.
Light now takes an explicit lower tone for the side:
onPrimaryFixedagainst the face'scolorPrimary, tone 10 against tone 40, at0.8alpha so it does not go too heavy. Dark keepsthe alpha, because there is no standard role a step below primary's tone 80 and alpha already
gives the right relationship against a dark background.
Measured from the rendered pixels — side darker than face in all three:
#006971#314B4E#445E91#314666#81D4DD#4D7D82M3's fixed roles were tried first and cannot do this:
primaryFixedis 1.23:1 on a lightbackground and
onPrimaryFixedis 1.09:1 on a dark one. Stable across modes, and invisible inone of them.
Size
The geometry is scaled 1.5× out of the adaptive-icon safe zone. It was drawn for a launcher, where
the mark occupies the middle 72dp of a 108dp canvas so the system can mask it — nothing masks it
here, so that padding rendered it two-thirds the size of the icon it replaced.
The on-screen size is 92dp, chosen by Shane on device.
Known limit
The mark cannot have the real icon's light mint face while it sits on a white surface — that works
on the launcher because the tile behind it is dark navy. Giving it a tile here would resolve it,
and was not attempted.
🤖 Generated with Claude Code
This pull request description was written by Claude Code.