A second life for a Moto X¶

Moto X Dashboard began with a phone that was too good to throw away.

The 2013 Moto X XT1058 still has a lovely AMOLED screen, a working battery, Wi-Fi, Bluetooth, and enough computing power to draw a clock. What it no longer has is a safe, useful life as an ordinary smartphone: its locked bootloader leaves it on Android 5.1, contemporary applications have moved on, and its browser is not a sensible foundation for a new product.

So the phone becomes something smaller and more deliberate: a dark bedside clock, a rotating household dashboard, and eventually a large-button player for a DRM-free music library and a humble Bluetooth shower speaker.

The first of those experiences is already real. The Android app renders two original clock faces entirely with native Java and Android Canvas APIs:

an amber Nixie-inspired night face with hand-drawn cathodes, rare electrical imperfections, burn-in movement, and matching synthesized sounds; and
a mid-century split-flap day face with baked mechanical cards, live type, a gravity-driven flip, and a procedural tick-and-clack.

The dashboard PoC now follows the same boundary: the old phone renders cached cards; a modern ASP.NET Core service fetches weather, baseball and headlines, selects content and renders bounded PNGs. The five-card evaluation pipeline is deployed on OVH. The XT1058 has displayed Bogotá weather, separate API-Sports and BALLDONTLIE Yankees cards, and both news cards over public HTTPS. The older MLB Stats source is disabled after its OVH edge returned HTTP 406. Shower Radio remains future work.

Choose a path¶

flowchart TD
    Start[What would you like to understand?]
    Start --> Story[Why this project exists]
    Start --> Clock[How the clock works]
    Start --> Platform[How the two surfaces fit together]
    Start --> Future[What comes next]
    Start --> Operate[How it is built and published]

    Story --> Vision[Product vision]
    Story --> Readme[Repository overview]
    Clock --> Rendering[Rendering algorithms]
    Clock --> Sound[Sound synthesis]
    Clock --> Preview[Preview tools]
    Platform --> Architecture[Architecture]
    Platform --> Android[Android 5.1 constraints]
    Platform --> Dashboard[Dashboard]
    Future --> Radio[Shower Radio]
    Operate --> Deployment[OVH deployment]
    Operate --> Export[Documentation export]

If you are interested in…	Start with…
The product, its mood, and its intentional limits	Product vision
The implemented clock as a user-facing feature	Clock overview
Canvas layers, cached masks, timing envelopes, or complexity	Clock rendering
The speaker-aware procedural audio	Sound synthesis
The implemented phone/server pipeline and its boundaries	Architecture
Building against API 22 with a current toolchain	Android 5.1 constraints
Source layout, builds, and local development	Repository README

What exists today¶

These labels are used throughout the site:

Status	Meaning
Implemented	Present in the source tree and covered by automated tests. Device-specific claims identify the XT1058 checks that were actually performed.
Implemented, tuning remains	The feature works, but bedside appearance, loudness, heat, or long-duration behavior still needs physical-device judgment.
Scaffolded	A narrow contract or project shell exists; the product capability does not.
Planned	Product direction has been recorded, but no implementation is claimed.

As of this documentation snapshot:

the two clock faces, theme scheduling, manual override, burn-in movement, quiet-hours policy, optional effects and sounds, and Preview tools are implemented;
final dark-room tuning and the overnight soak are still outstanding;
the authenticated API, four configured sources, PNG cards, client cache and dashboard modes are implemented, with API-22 automated device acceptance; the PoC plan tracks outstanding checks;
OVH runs the frozen provider release; three sources pass production/device checks, while MLB acceptance remains open. Two keyed baseball adapters are now configured locally for comparison, not yet part of that release. See Dashboard for the source choice and Deployment for the exact running revision; and
Shower Radio, private calendars, photographs and an admin UI are planned.

The documentation describes the repository snapshot, not a claim that every planned surface is deployed. For operational decisions, verify the revision running on the phone or server.

Design values¶

This is an appliance, not an attempt to make Android 5.1 modern again.

Keep the phone native, small, offline-tolerant, and visually quiet.
Put OAuth credentials and fast-changing integrations on the server.
Preserve normal HTTPS validation even when the old trust store needs a narrowly scoped compatibility path.
Spend GPU time only while something is changing.
Treat the AMOLED panel, the sleeping user, and a very small phone speaker as physical constraints—not abstractions to paper over.
Document the difference between a design, an implementation, a phone measurement, and a future idea.