System Requirements Document for billing-google-play

1. Introduction

This document specifies a strictly technical reference console for a single expert audience: an Android internal systems engineer / reverse engineer diagnosing why an in-app billing flow initiated through Google Play Store (com.android.vending) resolves to the wrong Google account on a multi-account device.

The product intent is to deliver a grounded, source-bounded reverse-engineering analysis of how Google Play determines the active buyer account for an in-app billing flow, together with actual CLI commands and code definitions. The console covers four investigative responsibilities:

1. Exact shell commands to query current account state and licensing bindings — package installer / licensing metadata via pm dump <package_name> or cmd package, and the system accounts database (/data/system_de/0/accounts_de.db) plus Google Auth token caches.
2. Direct CLI tests — whether cmd appops, cmd package, or am start intents with specific extras can force a specific account context when launching the game or the billing activity, and how Android's DevicePolicyManager (dpm) CLI interacts with account visibility or account restriction per user/profile.
3. Android multi-user / Work Profile automation via CLI — exact ADB/Termux commands (pm create-user, am switch-user, or dpm commands) to spin up an isolated profile with a single targeted Google account, clone the target APK into it, and launch it.
4. Feasibility analysis for a standalone manager app — which system permissions or architecture (Device Owner API vs. Shizuku privileged service vs. LSPosed Xposed hook on com.android.vending's billing AIDL interface) could intercept or dictate the account returned to the billing sheet, and the specific method signatures or AIDL interfaces within com.android.vending that handle buyer account resolution.

The audience is one persona: the Android Internal Systems Engineer / Reverse Engineer. The console is a workshop instrument — dense command output, method signatures, and probe tables — not a sanitized dashboard.

2. System Overview

The system is a first-party, read-only technical reference console. It presents diagnostic procedures, exact shell commands, expected-output strips, policy behavior notes, isolation automation recipes, architecture feasibility comparisons, and billing interface signatures. It does not execute privileged operations on the user's device on their behalf; the engineer runs the documented commands in Termux (non-root, root/su, ADB/Shizuku) and reads the results.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The console is delivered as a first-party web surface with no application-owned identity. Every page in the page contract carries access_requirement: none; there is no sign-in, no account creation, no session continuity, and no differentiated permissions. The engineer's device, Termux session, ADB/Shizuku connection, and root shell are external to the product and remain under the engineer's own control. The console never claims to hold, proxy, or store device credentials, Google account tokens, or Play Store state.

Current vs. future boundary. All eight accepted requirements are current. The console documents commands and signatures as reference material; it does not ship a manager app, does not ship an Xposed module, does not ship a Shizuku service, and does not perform billing interception. The feasibility analysis in the Manager Architecture and Billing Interfaces pages is analysis, not an implementation commitment.

Hard exclusions. Generic user-facing advice such as "clear cache" or "reinstall the app" is excluded from the product. The console is strictly technical: actual CLI commands and code definitions, not remediation tips.

Provider and external ownership. Google Play Store (com.android.vending), the Android framework (pm, cmd, am, dpm, appops), the Android accounts subsystem, Google Auth token caches, Shizuku, LSPosed/Xposed, and the target app/game are all external systems. The console documents how to interrogate and reason about them; it does not own them and does not modify them.

2b. Source Content Inventory

Not applicable. No reference directive in the authoritative sources declares content_source.

2c. Page Content and Component Coverage

The page contract is versioned (page_contract_version=1) and is copied exactly: seven pages, in order, each with access_requirement: none.

Landing

• Information / state. Anonymous first impression. Two-line VT323 masthead: WRONG BUYER ACCOUNT over com.android.vending. A live-probe command panel showing pm dump com.example.game | grep -i -A4 'billing\|license' with truncated output and a vermilion caret. A pixel flow diagram of buyer-account resolution with the account-picker node outlined in vermilion. A left rail of pixel-icon step tiles (Query, Probe, Isolate, Intercept) that doubles as navigation and progress.
• Primary actions. Navigate into any of the six investigative pages via the step-tile rail or the command stack. Copy the hero probe command.
• Supporting actions. Read the one-line purpose of each step tile; read the flow diagram legend.
• Domain entities. Target package name, billing/licensing dump excerpt, buyer-account resolution flow (BillingClient → Play Store billing service → account picker → chosen Account).
• Component responsibilities. Masthead; hero command panel with copy glyph; pixel flow diagram; step-tile rail with 8px progress fill; reduced-motion caret suppression.
• States. Loading: none (static reference content). Empty: not applicable. Success: command panel renders with truncated output and blinking caret. Error: if the hero probe excerpt is unavailable, the panel renders the command with an explicit "output not captured" mono label and a crossed-shield glyph. Recovery: the engineer copies the command and runs it in their own Termux session.

Account Inspection

• Information / state. Exact shell commands to query current account state and licensing bindings. Two command groups: (a) package installer / licensing metadata via pm dump <package_name> and cmd package; (b) the system accounts database at /data/system_de/0/accounts_de.db and Google Auth token caches. Each command is a bordered listing-paper block with a 32px pixel step numeral, a one-line purpose, a copyable mono command, and an expected-output strip.
• Primary actions. Copy any command block; read the expected-output strip; read the privilege annotation for each command.
• Supporting actions. Read the account-state table (strict tabular alignment, hairline row rules, right-aligned numeric columns); read the privilege glyph legend.
• Domain entities. Target package name; pm dump output sections; cmd package subcommands; accounts_de.db tables and columns; Google Auth token cache paths; privilege level (non-root, root/su, ADB/Shizuku).
• Component responsibilities. Command stack; expected-output strips; account-state table; privilege glyphs (check, padlock, crossed shield) with mono labels; copy-to-checkmark feedback.
• States. Loading: none. Empty: not applicable. Success: command block renders with copy glyph; copy flips border to vermilion and glyph to checkmark for 1.2s. Error: commands requiring root or Shizuku carry a padlock glyph and a mono "privilege required" label; commands blocked by policy carry a crossed-shield glyph and a mono "blocked/denied" label. Recovery: the engineer escalates privilege in their own shell or switches to the documented alternative command.

CLI Tests

• Information / state. Direct CLI tests for account-context selection. Three test families: cmd appops, cmd package, and am start intents with specific extras, each documented with the exact invocation, the extras or op names involved, and the observable result to look for when launching the game or the billing activity.
• Primary actions. Copy a test command; read the expected observable result; read the interpretation note for each test.
• Supporting actions. Read the appops-value table; read the intent-extras table.
• Domain entities. App-op names and modes; package subcommands; intent actions, components, and extras; target package name; billing activity component.
• Component responsibilities. Command stack; appops-value table; intent-extras table; interpretation notes; privilege glyphs.
• States. Loading: none. Empty: not applicable. Success: test command renders with copy glyph and expected-result strip. Error: tests that cannot force account context are marked with a crossed-shield glyph and a mono "no effect on account context" label rather than being omitted. Recovery: the engineer falls through to the User Isolation page for profile-level isolation.

Policy Controls

• Information / state. Explanation of how Android's DevicePolicyManager (dpm) CLI interacts with account visibility or account restriction per user/profile. Covers the relevant dpm subcommands, the account-visibility and account-restriction semantics, and the per-user / per-profile scope of each.
• Primary actions. Copy a dpm command; read the scope note (which user or profile it applies to); read the effect note.
• Supporting actions. Read the per-user / per-profile scope table.
• Domain entities. dpm subcommands; account visibility settings; account restriction settings; user IDs and profile IDs; device-owner and profile-owner context.
• Component responsibilities. Command stack; scope table; effect notes; privilege glyphs.
• States. Loading: none. Empty: not applicable. Success: command renders with scope and effect notes. Error: commands requiring device-owner or profile-owner context carry a padlock glyph and a mono "device owner required" label. Recovery: the engineer provisions the required owner context in their own environment or uses the documented non-owner alternative.

User Isolation

• Information / state. Exact ADB/Termux commands to spin up an isolated profile with a single targeted Google account, clone the target APK into it, and launch it. Covers pm create-user, am switch-user, and dpm commands, plus the APK install and launch steps for the isolated user.
• Primary actions. Copy a step command; read the expected result of each step; read the ordering note that ties the steps into a sequence.
• Supporting actions. Read the multi-user isolation diagram (user 0 / work profile 10 / cloned app with a single account) drawn with 1px ink strokes and vermilion for the path under investigation.
• Domain entities. User IDs; profile IDs; target package name; APK path; Google account to be added in the isolated profile; launch component.
• Component responsibilities. Numbered command stack; isolation diagram; ordering notes; privilege glyphs.
• States. Loading: none. Empty: not applicable. Success: each step renders with its expected result. Error: steps requiring root or Shizuku carry a padlock glyph; steps that fail on locked-down builds carry a crossed-shield glyph with a mono note. Recovery: the engineer removes the created user (pm remove-user) and retries with the documented alternative.

Manager Architecture

• Information / state. Feasibility analysis for a standalone manager app. Compares three architectures — Device Owner API, Shizuku privileged service, and LSPosed Xposed hook on com.android.vending's billing AIDL interface — against the question of which could intercept or dictate the account returned to the billing sheet. For each: the specific system permissions required, the reachable surface, and the honest capability boundary.
• Primary actions. Read each architecture's capability assessment; copy any referenced permission or manifest snippet.
• Supporting actions. Read the comparison table (architecture × reachable surface × required permission × verdict).
• Domain entities. Device Owner API; Shizuku privileged service; LSPosed/Xposed hook; billing AIDL interface; system permissions; target package name.
• Component responsibilities. Architecture comparison table; per-architecture capability notes; permission snippets; verdict glyphs.
• States. Loading: none. Empty: not applicable. Success: each architecture renders with its verdict. Error: architectures that cannot reach the billing account-resolution path are marked with a crossed-shield glyph and a mono "cannot dictate account" label. Recovery: the engineer reads the reachable-surface note to choose the architecture that can observe or influence the path.

Billing Interfaces

• Information / state. The specific method signatures and AIDL interfaces within com.android.vending that handle buyer account resolution. Signatures are rendered as tabular rows with hairline rules and right-aligned parameter types; the interface name sits in ink caps and the method name is underlined in vermilion when it is the account-resolution entry point.
• Primary actions. Copy a signature; read the parameter-type column; read the entry-point annotation.
• Supporting actions. Read the interface index; read the resolution-flow cross-reference back to the Landing diagram.
• Domain entities. AIDL interface names; method names; parameter types; return types; the account-resolution entry point.
• Component responsibilities. Signature table; interface index; entry-point annotations; resolution-flow cross-reference.
• States. Loading: none. Empty: not applicable. Success: signature rows render with entry-point underlines. Error: signatures that could not be verified against a specific Play Store build carry a mono "build-dependent" label rather than being presented as fixed. Recovery: the engineer verifies against their own com.android.vending build.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-1 — Reverse-engineering analysis of buyer-account resolution (explicit) As an Android Internal Systems Engineer / Reverse Engineer, I should receive a strictly technical reverse-engineering analysis of how Google Play (com.android.vending) determines the active buyer account for an in-app billing flow on a multi-account device, with actual CLI commands and code definitions.

• Trigger / input: The engineer opens the console.
• Observable result: The console presents the analysis across the Landing, Account Inspection, CLI Tests, Policy Controls, User Isolation, Manager Architecture, and Billing Interfaces pages.
• Access state: Anonymous; no identity required.
• Failure / recovery: If a specific Play Store build's behavior differs, the console marks the affected claim as build-dependent and the engineer verifies against their own build.
• Continuation: The engineer proceeds to the specific investigative page for their current question.

FR-2 — Query current account state and licensing bindings (explicit) As an Android Internal Systems Engineer / Reverse Engineer, I should get exact shell commands to query the current account state and licensing bindings: inspecting package installer / licensing metadata via pm dump <package_name> or cmd package, and querying the system accounts database (/data/system_de/0/accounts_de.db) and Google Auth token caches.

• Trigger / input: The engineer opens Account Inspection.
• Observable result: Command blocks for pm dump <package_name>, cmd package, accounts_de.db queries, and Google Auth token cache paths, each with a copyable command and an expected-output strip.
• Access state: Anonymous; commands run in the engineer's own Termux/ADB/Shizuku shell.
• Failure / recovery: Commands requiring root or Shizuku carry a padlock glyph and a mono "privilege required" label; the engineer escalates privilege or uses the documented alternative.
• Continuation: The engineer reads the account-state table to interpret the output.

FR-3 — Direct CLI tests for account-context selection (explicit) As an Android Internal Systems Engineer / Reverse Engineer, I should get direct CLI tests answering whether cmd appops, cmd package, or am start intents with specific extras can force a specific account context when launching the game or the billing activity.

• Trigger / input: The engineer opens CLI Tests.
• Observable result: Test commands for cmd appops, cmd package, and am start with specific extras, each with the exact invocation and the observable result to look for.
• Access state: Anonymous; tests run in the engineer's own shell.
• Failure / recovery: Tests that cannot force account context are marked with a crossed-shield glyph and a mono "no effect on account context" label rather than omitted.
• Continuation: The engineer falls through to User Isolation for profile-level isolation.

FR-4 — DevicePolicyManager CLI account visibility and restriction behavior (explicit) As an Android Internal Systems Engineer / Reverse Engineer, I should get an explanation of how Android's DevicePolicyManager (dpm) CLI interacts with account visibility or account restriction per user/profile.

• Trigger / input: The engineer opens Policy Controls.
• Observable result: dpm subcommands with per-user / per-profile scope notes and effect notes.
• Access state: Anonymous; commands run in the engineer's own shell.
• Failure / recovery: Commands requiring device-owner or profile-owner context carry a padlock glyph and a mono "device owner required" label.
• Continuation: The engineer applies the scope note when designing the isolation recipe on User Isolation.

FR-5 — Multi-user / Work Profile isolation automation (explicit) As an Android Internal Systems Engineer / Reverse Engineer, I should get exact ADB/Termux commands (pm create-user, am switch-user, or dpm commands) to spin up an isolated profile with a single targeted Google account, clone the target APK into it, and launch it.

• Trigger / input: The engineer opens User Isolation.
• Observable result: A numbered command sequence covering user creation, user switch, targeted account setup, APK install, and launch, each with its expected result.
• Access state: Anonymous; commands run in the engineer's own shell.
• Failure / recovery: Steps requiring root or Shizuku carry a padlock glyph; steps that fail on locked-down builds carry a crossed-shield glyph with a mono note; the engineer removes the created user and retries with the documented alternative.
• Continuation: The engineer launches the cloned app in the isolated profile and observes which account the billing sheet resolves to.

FR-6 — Standalone manager app feasibility analysis (explicit) As an Android Internal Systems Engineer / Reverse Engineer, I should get a feasibility analysis for a standalone manager app: which system permissions or architecture (Device Owner API vs. Shizuku privileged service vs. LSPosed Xposed hook on com.android.vending's billing AIDL interface) could intercept or dictate the account returned to the billing sheet.

• Trigger / input: The engineer opens Manager Architecture.
• Observable result: A comparison of the three architectures against reachable surface, required permission, and verdict.
• Access state: Anonymous.
• Failure / recovery: Architectures that cannot reach the billing account-resolution path are marked with a crossed-shield glyph and a mono "cannot dictate account" label.
• Continuation: The engineer reads the reachable-surface note to choose the architecture that can observe or influence the path.

FR-7 — Billing AIDL interfaces and method signatures (explicit) As an Android Internal Systems Engineer / Reverse Engineer, I should get the specific method signatures or AIDL interfaces within com.android.vending that handle buyer account resolution.

• Trigger / input: The engineer opens Billing Interfaces.
• Observable result: A signature table with interface names in ink caps, method names underlined in vermilion at the account-resolution entry point, and right-aligned parameter types.
• Access state: Anonymous.
• Failure / recovery: Signatures that could not be verified against a specific Play Store build carry a mono "build-dependent" label.
• Continuation: The engineer cross-references the resolution flow on Landing.

FR-8 — Exclusion of generic user-facing advice (explicit) As an Android Internal Systems Engineer / Reverse Engineer, I should not be given generic user-facing advice such as "clear cache" or "reinstall the app".

• Trigger / input: Any page render.
• Observable result: No page presents "clear cache", "reinstall the app", or equivalent generic remediation as a fix.
• Access state: Anonymous.
• Failure / recovery: Not applicable; this is a content exclusion enforced at authoring time.
• Continuation: Not applicable.

4. User Personas

Android Internal Systems Engineer / Reverse Engineer

Product context. A single expert practitioner diagnosing a concrete defect: an Android app/game initiates an in-app billing flow via Google Play Store (com.android.vending), but the billing bottom sheet resolves to the wrong Google account on a multi-account device. They work hands-on in Termux and ADB, across non-root, root/su, and ADB/Shizuku privilege levels, and they read dense command output and method signatures for a living.

Primary goal. Reach a technically grounded explanation of how Google Play determines the active buyer account, backed by exact commands, method signatures, and AIDL interfaces — and know whether that state can be manipulated programmatically.

Distinct accepted responsibilities.

• Run Termux CLI probes (non-root, root/su, ADB/Shizuku) to query account state and licensing bindings.
• Test cmd appops, cmd package, and am start intents with specific extras for account-context selection.
• Test dpm account-visibility and account-restriction behavior per user/profile.
• Automate multi-user / Work Profile isolation via pm create-user, am switch-user, and dpm, then clone the target APK into the isolated profile and launch it.
• Evaluate Device Owner vs. Shizuku vs. LSPosed architectures for a standalone manager app.
• Read and verify com.android.vending billing AIDL interfaces and method signatures for buyer-account resolution.

Relevant inputs or decisions. The target package name; the observed wrong-account behavior; the privilege level available on the test device; the Play Store build under test; the choice of isolation approach (new user vs. work profile); the choice of architecture for a potential manager app.

Interactions with other accepted participants. None. This is the only accepted active human persona. All other actors — Google Play Store, the Android framework, the accounts subsystem, Google Auth token caches, Shizuku, LSPosed/Xposed, and the target app/game — are external systems, not personas.

Observable success. A grounded explanation of how com.android.vending resolves the buyer account, plus concrete commands, method signatures, and AIDL interfaces that the engineer can run and verify against their own device.

What makes this role's work different. The role is investigative and adversarial toward the machine: it interrogates a closed-source system through its CLI surfaces and its AIDL boundary, and it needs the console to be a workshop instrument — dense, exact, and copy-ready — rather than a guided workflow. There is no onboarding, no account, and no hand-holding; the value is in the precision of the commands and signatures.

5. Core User Flows

Flow A — Establish the investigation context (Landing)

1. The engineer opens the console at Landing. No identity is required.
2. The engineer reads the two-line masthead WRONG BUYER ACCOUNT / com.android.vending and the hero probe command panel showing pm dump com.example.game | grep -i -A4 'billing\|license' with truncated output and a blinking vermilion caret.
3. The engineer reads the pixel flow diagram of buyer-account resolution (BillingClient → Play Store billing service → account picker → chosen Account), noting the account-picker node outlined in vermilion.
4. The engineer copies the hero probe command and runs it in their own Termux session to confirm the target package's billing/licensing dump is reachable.
5. Result: the engineer has a working probe and a mental model of the resolution path.
6. Failure / recovery: if the hero probe excerpt is unavailable, the panel shows the command with an "output not captured" mono label and a crossed-shield glyph; the engineer still copies and runs the command.
7. Continuation: the engineer selects the step tile for their current question — Query, Probe, Isolate, or Intercept.

Flow B — Query account state and licensing bindings (Account Inspection)

1. The engineer opens Account Inspection.
2. The engineer copies the pm dump <package_name> command and runs it in Termux, then reads the expected-output strip to locate the billing/licensing sections.
3. The engineer copies the cmd package command variant and runs it, comparing the output against the account-state table.
4. The engineer copies the accounts_de.db query for /data/system_de/0/accounts_de.db and runs it with the required privilege.
5. The engineer copies the Google Auth token cache inspection command and runs it with the required privilege.
6. Result: the engineer has the current account state and licensing bindings for the target package.
7. Failure / recovery: commands requiring root or Shizuku show a padlock glyph and a mono "privilege required" label; the engineer escalates privilege in their own shell or uses the documented alternative. Commands blocked by policy show a crossed-shield glyph and a mono "blocked/denied" label.
8. Continuation: the engineer moves to CLI Tests to attempt account-context selection.

Flow C — Test direct CLI account-context selection (CLI Tests)

1. The engineer opens CLI Tests.
2. The engineer copies the cmd appops test, runs it, and reads the appops-value table to interpret the result.
3. The engineer copies the cmd package test, runs it, and reads the expected observable result.
4. The engineer copies the am start intent test with the documented extras, launches the game or the billing activity, and observes which account the billing sheet resolves to.
5. Result: the engineer knows whether cmd appops, cmd package, or am start extras can force a specific account context.
6. Failure / recovery: tests that cannot force account context are marked with a crossed-shield glyph and a mono "no effect on account context" label; the engineer does not treat them as a fix and falls through to profile-level isolation.
7. Continuation: the engineer moves to Policy Controls to understand dpm account visibility and restriction.

Flow D — Understand dpm account visibility and restriction (Policy Controls)

1. The engineer opens Policy Controls.
2. The engineer copies a dpm subcommand, runs it, and reads the per-user / per-profile scope note to confirm which user or profile it applies to.
3. The engineer reads the effect note to understand how the command changes account visibility or account restriction.
4. Result: the engineer knows how dpm interacts with account visibility and restriction per user/profile.
5. Failure / recovery: commands requiring device-owner or profile-owner context show a padlock glyph and a mono "device owner required" label; the engineer provisions the owner context in their own environment or uses the documented non-owner alternative.
6. Continuation: the engineer moves to User Isolation to build the isolated profile.

Flow E — Isolate a profile with a single targeted account (User Isolation)

1. The engineer opens User Isolation.
2. The engineer copies the pm create-user command and runs it, then reads the expected result to confirm the new user ID.
3. The engineer copies the am switch-user command and runs it to switch to the new user.
4. The engineer follows the targeted-account setup steps to add a single Google account in the isolated profile.
5. The engineer copies the APK install command to clone the target APK into the isolated user.
6. The engineer copies the launch command and launches the cloned app.
7. Result: the target app runs in an isolated profile with a single targeted Google account, and the engineer observes which account the billing sheet resolves to.
8. Failure / recovery: steps requiring root or Shizuku show a padlock glyph; steps that fail on locked-down builds show a crossed-shield glyph with a mono note; the engineer removes the created user (pm remove-user) and retries with the documented alternative.
9. Continuation: the engineer moves to Manager Architecture to evaluate a standalone manager app.

Flow F — Evaluate manager app architectures (Manager Architecture)

1. The engineer opens Manager Architecture.
2. The engineer reads the comparison table across Device Owner API, Shizuku privileged service, and LSPosed Xposed hook on com.android.vending's billing AIDL interface.
3. For each architecture, the engineer reads the reachable surface, the required system permission, and the verdict.
4. The engineer copies any referenced permission or manifest snippet.
5. Result: the engineer knows which architecture could intercept or dictate the account returned to the billing sheet, and which cannot.
6. Failure / recovery: architectures that cannot reach the billing account-resolution path show a crossed-shield glyph and a mono "cannot dictate account" label; the engineer reads the reachable-surface note to choose the architecture that can observe or influence the path.
7. Continuation: the engineer moves to Billing Interfaces to read the exact signatures.

Flow G — Read billing AIDL interfaces and signatures (Billing Interfaces)

1. The engineer opens Billing Interfaces.
2. The engineer reads the signature table, noting interface names in ink caps and the account-resolution entry point underlined in vermilion.
3. The engineer reads the right-aligned parameter types and the interface index.
4. The engineer copies a signature and cross-references the resolution flow on Landing.
5. Result: the engineer has the specific method signatures and AIDL interfaces within com.android.vending that handle buyer account resolution.
6. Failure / recovery: signatures that could not be verified against a specific Play Store build carry a mono "build-dependent" label; the engineer verifies against their own com.android.vending build.
7. Continuation: the engineer returns to Account Inspection or CLI Tests to validate the signatures against observed behavior.

6. Visuals Colors and Theme

Muse: Susan Kare. Headline: Charming clarity for a billing forensics console.

The direction is authoritative for this section. It is translated into concrete tokens below.

Color tokens (light mode)

Status glyph signal set (reserved strictly for status glyphs, never for text):

All body text sits on paper or white at ≥7:1 contrast.

Typography

Scale: 1.333 modular.

Shape language

Pixel-grid honesty: 2px radius on panels (essentially square, with a 1px inset highlight on the top-left edge to read as a raised tile); 1px solid ink borders everywhere; chunky 3px borders around command blocks; 8px pixel-corner notches on the four corners of primary panels instead of rounded corners. Buttons are rectangular tiles that depress 2px on press with no easing overshoot. Status is carried by 16×16 pixel glyphs — a checkmark, a padlock, a crossed-out shield — drawn on the same grid as the type.

Spacing rhythm

A strict grid: the masthead's second line indents to grid column 8; command stack entries align to the same column; tables use hairline row rules with right-aligned numeric columns.

Imagery style

No photography. Pixel pictograms on a 16×16 grid — a package box, an account key, a user-profile silhouette, a padlock, a terminal chevron, a shield with a slash — plus schematic diagrams drawn with 1px ink strokes and vermilion for the path under investigation.

7. Signature Design Concept

The public entry (Landing) is a working instrument, not a pitch.

A full-bleed warm-paper field (#F4F1E9) carries, at the top, a VT323 headline spanning the viewport in two stacked lines — WRONG BUYER ACCOUNT over com.android.vending — set at clamp(44px, 7vw, 88px), flush left, with the second line indented to grid column 8 so the two lines lock into the page grid.

Immediately beneath sits a 3px-bordered black command panel (white surface, IBM Plex Mono) showing a live probe: pm dump com.example.game | grep -i -A4 'billing\|license' with its truncated output and a vermilion caret blinking at the prompt.

To the right on desktop (below on mobile) sits the pixel flow diagram of buyer-account resolution, with the account-picker node outlined in vermilion.

There is no centred headline, no subtext-plus-button stack, no gradient, and no illustration hero. The dominant element is the command panel and the oversized two-line wordmark.

Signature moves carried through the console:

• The two-line VT323 masthead with the command panel pinned directly beneath it rather than a CTA button.
• Every command is a bordered listing-paper block: 3px ink border, white surface, IBM Plex Mono, a 32px pixel step numeral in the top-left notch, and a copy glyph that flips to a checkmark in vermilion for 1.2s on copy.
• A left rail of 16×16 pixel pictogram step tiles (package box, account key, profile silhouette, padlock, slashed shield) that doubles as navigation and fills with an 8px solid progress bar as each section is read.
• AIDL signatures rendered as tabular rows with hairline rules and right-aligned parameter types, where the interface name sits in ink caps and the method name is underlined in vermilion when it is the account-resolution entry point.
• Status is never colour alone: each probe result carries a pixel glyph (check, padlock, crossed shield) plus a mono label, so pass / privilege-required / blocked read identically in greyscale.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the hero command panel showing the live probe pm dump com.example.game | grep -i -A4 'billing\|license' with truncated output, and the pixel flow diagram of buyer-account resolution with the account-picker node outlined in vermilion.
• Input → transformation → outcome thesis: the engineer copies the probe command (input); the command block's border flips to vermilion and its glyph swaps to a checkmark for 1.2s (transformation); the engineer runs the command in their own Termux session and reads the billing/licensing dump (outcome). No accepted behaviour is added — the motion only confirms that a command was copied.
• Motion vocabulary: restrained and mechanical — 120ms instant state changes, no easing theatre; a copy action flips the command block's border to vermilion and swaps the glyph to a checkmark for 1.2s; step tiles fill with a solid 8px pixel progress bar as their section is read; the only ambient motion is a 1px caret blink in the active command block.
• Composed first frame: warm-paper field; two-line VT323 masthead flush left with the second line indented to grid column 8; the 3px-bordered command panel directly beneath with the probe command and a vermilion caret at the prompt; the pixel flow diagram to the right on desktop (below on mobile) with the account-picker node outlined in vermilion.
• Reduced-motion state: the caret blink stops entirely under prefers-reduced-motion; the copy confirmation becomes an instant border-and-glyph swap with no timed hold; the step-tile progress bar renders as a static filled segment.

9. Non-Functional Requirements

NFR-1 — Strictly technical content (explicit) The console must be strictly technical and must provide actual CLI commands and code definitions. Rationale: the engineer needs copy-ready commands and signatures, not prose summaries.

NFR-2 — No generic user-facing advice (explicit) The console must not present generic user-facing advice such as "clear cache" or "reinstall the app". Rationale: such advice is excluded by the authoritative source and is not a fix for the diagnosed defect.

NFR-3 — Copy fidelity (required_inference) Command blocks and AIDL signatures must be copyable verbatim, with no smart-quote substitution, no line-wrapping mid-flag, and no truncation of the copied text. Rationale: the engineer runs these commands directly; a mangled flag or a wrapped pipe breaks the probe. Command blocks scroll horizontally inside their own bordered box rather than wrapping mid-flag.

NFR-4 — Privilege transparency (required_inference) Every command must carry an explicit privilege annotation (non-root, root/su, ADB/Shizuku, device-owner, profile-owner) rendered as a pixel glyph plus a mono label, so pass / privilege-required / blocked read identically in greyscale. Rationale: the engineer must know before running a command whether their current shell can execute it.

NFR-5 — Readable text and controls at every viewport (explicit, from the creative direction) Headlines, wordmarks, labels, numbers, cards' text and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element may cover any part of them. At 375px the left rail collapses to a horizontally scrollable strip of icon tiles above the command stack. Rationale: the direction's readability rule takes precedence for readable text and controls.

NFR-6 — Reduced-motion compliance (explicit, from the creative direction) Under prefers-reduced-motion, the caret blink stops entirely and all motion resolves to static states. Rationale: the direction specifies that the only ambient motion is the caret blink and that it stops under reduced motion.

NFR-7 — No blue-on-white SaaS look (explicit, from the creative direction) The generic indigo/blue-on-white SaaS template is forbidden. Blue-indigo accents (#2563EB, #4F46E5, #6366F1 and neighbours), Inter/Roboto/Arial/Helvetica/Poppins/Lato/Open Sans/system-ui for headings or body, gradient-blob heroes, frosted glass panels, grids of identical hover-lift cards, rounded 16–24px radii, soft drop shadows, and photographic stock imagery are all excluded. Rationale: the direction's avoid list is binding.

NFR-8 — Contrast (explicit, from the creative direction) All body text must sit on paper or white at ≥7:1 contrast. Rationale: the direction specifies this contrast floor.

10. Tech Stack

The authoritative sources do not specify a technology stack for the console. The following are coherent defaults, labeled as such.

• Frontend: React with a static-site build. [Default — not specified by user]
• Styling: CSS with custom properties for the color, type, and shape tokens in Section 6. [Default — not specified by user]
• Fonts: VT323, IBM Plex Mono, and IBM Plex Sans, self-hosted. [Default — not specified by user]
• Content: Static Markdown/MDX content for the command stack, tables, and signature index. [Default — not specified by user]
• Backend: None required. The console is a read-only reference surface with no application-owned identity and no server-side state. [Default — not specified by user]
• Storage: None required. [Default — not specified by user]
• Deployment: Static hosting. Docker/docker-compose and Kubernetes are not required for a static reference console. [Default — not specified by user]

The engineer's own tooling — Termux, ADB, Shizuku, root/su, LSPosed/Xposed, and the target device — is external to the product and is documented, not bundled.

11. Assumptions and Constraints

Assumptions

• A-1. The engineer has access to a multi-account Android device on which the wrong-account behavior can be reproduced. (Assumption — not specified by user.)
• A-2. The engineer has at least one of the documented privilege levels available (non-root, root/su, ADB, or Shizuku) for the commands that require it. (Assumption — not specified by user.)
• A-3. The target package name is known to the engineer and is substituted into the documented commands. (Assumption — not specified by user.)
• A-4. The com.android.vending build under test may differ from the build the signatures were verified against; signatures are marked build-dependent where verification is not possible. (Assumption — not specified by user.)
• A-5. The console is a reference surface; the engineer executes all commands in their own environment. (Assumption — not specified by user.)

Constraints

• C-1. Be strictly technical and provide actual CLI commands and code definitions. (Explicit.)
• C-2. Avoid generic user-facing advice like "clear cache" or "reinstall the app". (Explicit.)
• C-3. The console carries no application-owned identity; every page has access_requirement: none. (From the page contract.)
• C-4. The console does not ship a manager app, an Xposed module, or a Shizuku service; the Manager Architecture page is analysis only. (From the delivery boundary.)
• C-5. Google Play Store, the Android framework, the accounts subsystem, Google Auth token caches, Shizuku, LSPosed/Xposed, and the target app/game remain external systems with their accepted owners. (From the delivery boundary.)
• C-6. The creative direction's palette, typography, shape language, layout, motion, and avoid list are binding for the console's presentation. (Explicit, from the creative direction.)

12. Glossary

• Buyer account — The Google account that Google Play (com.android.vending) resolves as the payer for an in-app billing flow.
• Billing bottom sheet — The Play Store surface presented to the user when an app initiates an in-app purchase.
• com.android.vending — The Google Play Store package; the system component that owns billing account resolution.
• Billing AIDL interface — The Android Interface Definition Language boundary exposed by com.android.vending through which billing clients and the Play Store billing service communicate.
• pm — Android's package manager shell command; used for pm dump, pm create-user, and related operations.
• cmd package — The cmd-dispatched package service interface; an alternative to pm for package and licensing queries.
• cmd appops — The cmd-dispatched app-ops interface; used to read and set per-app operation modes.
• am start — The activity manager shell command for launching an activity, optionally with specific extras.
• am switch-user — The activity manager shell command for switching the foreground Android user.
• dpm — The DevicePolicyManager shell command; used to inspect and set device- and profile-owner policy, including account visibility and account restriction.
• accounts_de.db — The system accounts database at /data/system_de/0/accounts_de.db; holds the device's account records.
• Google Auth token cache — On-device storage of Google authentication tokens associated with signed-in accounts.
• Device Owner API — The Android device-administration API available to an app provisioned as device owner.
• Shizuku — A privileged service bridge that lets an app call system APIs with ADB-level privileges.
• LSPosed / Xposed — A hooking framework that can intercept method calls in a target process, including com.android.vending.
• Work profile — A managed Android profile (typically user 10) isolated from the primary user.
• Isolated profile — A newly created Android user or profile containing a single targeted Google account, used to control which account the billing sheet can resolve.
• Privilege level — The execution context of a command: non-root, root/su, ADB, Shizuku, device-owner, or profile-owner.
• Listing-paper block — The console's bordered command block: 3px ink border, white surface, IBM Plex Mono, 32px pixel step numeral, copy glyph.
• Step tile — A 16×16 pixel pictogram tile in the left rail that doubles as navigation and progress.