From iOS-only to Android-ready

Android is not iOS wearing a green jacket

The most common way to make mistakes in the so-called "adaptation from iOS to Android" is to copy the screenshot of the page pixel by pixel.What really needs to be migrated is the product contract: the user can only enter a Chinese character once to the remote end; SSH cannot be disconnected if the renderer fails; the new frame must be seen when returning from the background; the current plan must be recognized for subscription recovery; the Pad is not a mobile phone that is enlarged horizontally.

So each capability is translated into three layers: shared semantics, platform implementation, and evidence boundary.iOS can use its own viewport primitive, and Android can use Ghostty ABI 3; but "finger down to browse the older history and click to return to live" must be consistent.

flowchart LR
  I["iOS already has the ability"] --> C{"shared product contract"}
  C --> A["Android native implementation"]
  A --> D["Platform differentiation strategy"]
  D --> V["Three devices and real service verification"]
  V --> R{"Evidence passed?"}
  R -- "no" --> F["Locate the root cause and narrow the claim"]
  F --> V
  R -- "yes" --> S["Mini-batch review and atomic submission"]
            

Cross-platform is not about "looking the same", but "keeping the same promise even when something goes wrong".

Make Ghostty fail before letting it succeed

The first rule of Android Ghostty is a bit counter-intuitive: never start out optimistic.Synchronous constants are always set to `ok=false` first. The asynchronous self-test must prove that native core, ABI, VT, EGL, shader, texture upload, draw and readback are all true before switching from xterm to Ghostty.

This avoids the classic mobile metaphysics of "dark it first and then talk about it" in the first frame.There is also a 2.5-second upper limit for health certification: if the GPU really wants to enter meditation, the user can watch the spinner for up to 2.5 seconds, and then get a working xterm instead of a Zen-like permanent blank.

stateDiagram-v2
  [*] --> Pending
  Pending --> Ghostty: health proof succeeds before timeout
  Pending --> Xterm: timeout or proof fails
  Ghostty --> Xterm: runtime GL failure
  Xterm --> StableSession: same transport and ring replay
  Ghostty --> StableSession: native renderer active
  StableSession --> [*]
  note right of Ghostty
    Native VT plus full GL path
  end note
            

The terminal film is a representation of the article restoration, not the original image of the operation background; markers, results and boundaries are from real equipment evidence.

Those hard bones that are "easily" put together

Input method composition, xterm key sequence, touch selection, ActionMode copy, native scrollback, background compositor, PixelCopy probe, CPU snapshot, Pad keyboard focus mode... each item looks like P3 individually, but when stacked together, it determines "is this a terminal or a flashing black rectangle".

The browser had access, but no ready-made key

The permissions of Play Console are in the logged-in Chrome profile; the built-in Playwright is a clean profile and nothing can be seen; CDP has not been opened yet.The easiest answer is "ask the user to do it manually".Goal chose another path: first find out which browser context has permissions, and then compress user participation into a necessary consent.

If there is no ready-made bridge, generate one in the temporary directory: MCP SDK + `chrome-devtools-mcp` + thin stdio client, and then use persistent PTY to continuously send `snapshot → click → snapshot`.It is not packaged as a "platform capability" and is cleaned up after completion; the truly reusable conclusion is a dedicated profile, origin allowlist, fixed version and default desensitization.

sequenceDiagram
  actor U as user
  participant A as Goal Agent
  participant B as Chrome
  participant G as gcloud
  participant P as Play Publisher API
  participant R as RevenueCat API
  A->>B: Found that there is already a login state and target account context
  U->>B: Explicitly allow remote debugging
  B-->>A: CDP page control available
  A->>G: Enable the API and create two sets of least privileged identities
  A->>B: Bind app permissions in Play Console
  A->>P: Create catalog idempotently and upload internal AAB
  A->>R: Create Android app and product mapping
  P-->>A: track and artifact status
  R-->>A: entitlement and offering status
  A-->>U: Request only business facts and irreversible release decisions
            

A black screenshot is not a GPU obituary

The most dangerous moment for Android phone verification is when the first screenshot looks very convincing.SurfaceView may be completely black in system screenshots; Xiaomi screencap may be 0 bytes; screenrecord may only record the world without hardware layer.Conversely, when the remote tmux sees the marker, it only proves that the transport is alive, but not that the local compositor drew it.

Therefore, the evidence is designed as multiple oracles: unique marker, UI tree, PixelCopy, CPU raster, PID, dumpsys, logcat, and remote pane.They must falsify each other, not line up and applaud.

flowchart TB
  M["Inject unique marker"] --> U["UI tree and control status"]
  M --> X["Screenshot or PixelCopy"]
  M --> S["PID · dumpsys · logcat"]
  M --> T["Remote SSH/Mosh/tmux status"]
  U --> C{"Are multiple oracles consistent?"}
  X --> C
  S --> C
  T --> C
  C -- "no" --> A["Classifying test artifacts"]
  A --> N["Replace nonce and oracle and rerun"]
  N --> M
  C -- "yes" --> B["Write bounded conclusions"]
            

The truth about ‘fully automatic’: people appear only where they add value

The logical duration of the Goal this time is 21 hours, 54 minutes and 42 seconds, but the machine uptime is shorter.It is not a mysterious process that insists on not sleeping, but relies on Git, tmux, pollable tools, plan status, review handoff, and external system status to continuously restore context.

Users in this round have very little actual participation: log in to RevenueCat, complete a small number of clicks in the Chrome/Google Developer Console that must be confirmed by the account holder, and give explicit authorization for irreversible actions such as commit/push.Login status discovery, most Play form filling and fact checking, gcloud/permission opening, API generation, device verification, purchase/restoration testing, screenshot recording, error recovery and sorting are all closed loop by Goal itself.

flowchart TB
  O["Stable Goal goal"] --> P["Stage plan and evidence threshold"]
  P --> G["Git atomic commit"]
  P --> T["tmux and pollable tools"]
  P --> E["Device and external service status"]
  P --> R["independent reviewer verdict"]
  G --> C["Continue after process or boot change"]
  T --> C
  E --> C
  R --> C
  C --> P
            

Ten things the final diff does not tell you

What can the next app copy?

The last counter-intuitive conclusion

The truly communicable AI engineering story is not "it worked for 22 hours straight", but "it knew when to do it on its own, when to look for evidence, when to admit that screenshots are not trustworthy, and when to have people click on it."The upper limit of automation is not determined by the number of clicks, but by the sense of boundaries.

The best Agent does not make every decision for you; it compresses your involvement to the few moments that truly require a call.