Skip to content

alpha.20: nav-bar settings for every module, player-resolved downloads, programmed Brick tags - #21

Merged
codebooo merged 1 commit into
mainfrom
claude/lifeos-production-plan-v3-dmynx3
Jul 28, 2026
Merged

alpha.20: nav-bar settings for every module, player-resolved downloads, programmed Brick tags#21
codebooo merged 1 commit into
mainfrom
claude/lifeos-production-plan-v3-dmynx3

Conversation

@codebooo

Copy link
Copy Markdown
Owner

Three device-reported fixes (0.1.0-alpha.20).

1. Nav-bar setting was missing

The Settings section existed but its label map was still the original four entries, so nothing else could be selected. It now lists every module and gained a searchable "Add a module as a tab" picker.

Also fixed a real bug this exposed: with no stored selection the bottom bar fell back to all destinations, which would have put 27 tabs in the bar. The default is Home + Calendar/Tasks/Inbox/Jarvis again.

2. ThisVid downloads (404s and a zero-length file)

Root cause: the hand-rolled kt_player (KVS) decoder produced wrong URLs. Verified against a live page - the scrambled link is unscrambled by obfuscated per-session JavaScript, the hash changes on every page load, and the resulting URL is bound to the session (cookies plus a Referer check). No static reimplementation stays correct.

Fix:

  • Removed the decoder.
  • Added PlayerResolver: the page loads in an offscreen WebView, its own player is muted and nudged into playing, and the media request it issues is recorded along with the session cookies. Used when the static scan sees a scrambled player, or finds nothing.
  • MediaCandidate now carries request headers, and the download engine sends them (Referer, Cookie, User-Agent) for direct files and HLS segments alike.
  • Teasers, sprites, timeline previews and ad creatives are filtered out, so the zero-length preview clip no longer appears as a candidate.

The WebView is created, driven and destroyed inside the call; nothing is shown and nothing leaves the phone. Because these links are session-bound, the UI now says to download them straight away.

3. Brick NFC taps with the app closed

Reading a tag's serial number requires reader mode, which only runs while LifeOS is in front - hence "works only while the app is open". For a closed app, the tag itself has to carry something the system can route.

Fix:

  • Pairing now writes a LifeOS MIME record plus an Android Application Record onto the tag. The MIME record matches Brick's intent filter and the application record makes LifeOS win the dispatch outright, so no chooser appears.
  • The tag id is read from that record when present, falling back to the serial.
  • Broader NDEF/TECH/TAG filters and a fuller technology list, so tags written by other tools still land in Brick.
  • Pairing reports whether the tag could be programmed (read-only or non-NDEF tags still work, but only with the app open), and an NFC-off banner opens NFC settings.

No runtime permission exists for NFC - it is a manifest permission plus the system toggle, so the banner is the grant path. One limit worth stating: Android does not dispatch tags while the screen is locked, so the phone has to be unlocked for a tap to register. That is enforced by the platform, not by LifeOS.

Verification

:app:assembleDebug, :app:assembleRelease (minified) and the full test task pass.


Generated by Claude Code

…med Brick tags

Navigation bar
- The Settings section still listed only Calendar/Tasks/Inbox/Jarvis; it now
  lists every module, with a searchable "Add a module as a tab" picker.
- Fixed the default bar: an empty stored list meant every destination became a
  tab. It falls back to Home + Calendar/Tasks/Inbox/Jarvis again.

Downloader
- Dropped the hand-rolled kt_player (KVS) link decoder. Its output was wrong,
  which is where the 404s and the zero-length file came from: those links are
  scrambled by obfuscated per-session JavaScript and bound to the browsing
  session.
- Added PlayerResolver: the page runs in an offscreen WebView, the player is
  muted and nudged into playing, and the media request it makes is recorded
  along with the session cookies. Used when the static scan finds a scrambled
  player or nothing at all.
- MediaCandidate carries request headers, and the download engine sends them
  (Referer, Cookie, User-Agent) for both direct files and HLS segments, which
  is what those links require.
- Teasers, sprites, timeline previews and ad creatives are filtered out of the
  candidate list.

Brick NFC
- Pairing now programs the tag: a LifeOS MIME record plus an Android
  Application Record. That is what makes a tap reach LifeOS with the app
  closed, and it stops a chooser from appearing.
- Tag id is read from that record when present, falling back to the serial.
- Broader NDEF, TECH and TAG filters plus a fuller technology list, so
  tags written by other tools still land in Brick.
- Pairing reports whether the tag could be programmed, and an NFC-off banner
  opens NFC settings. Both places state plainly that Android only dispatches
  tags while the screen is unlocked.

Version 0.1.0-alpha.20.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011kSsXNrSk6NDjM2FjFZ7Y9
@codebooo
codebooo force-pushed the claude/lifeos-production-plan-v3-dmynx3 branch from 1393592 to ccd519d Compare July 28, 2026 18:17
@codebooo
codebooo merged commit a078838 into main Jul 28, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants