core: route RCS and carrier auth off DummyService

docs/juzi/apk_preflight.py

@@ -0,0 +1,66 @@
+#!/usr/bin/env python3
+"""
+Quick APK integrity preflight before BrowserStack upload.
+"""
+
+from __future__ import annotations
+
+import argparse
+import hashlib
+import sys
+import zipfile
+from pathlib import Path
+
+
+def sha256sum(path: Path) -> str:
+    h = hashlib.sha256()
+    with path.open("rb") as f:
+        for chunk in iter(lambda: f.read(1024 * 1024), b""):
+            h.update(chunk)
+    return h.hexdigest()
+
+
+def main() -> int:
+    parser = argparse.ArgumentParser(description="APK preflight checks")
+    parser.add_argument("apk", type=Path, help="Path to APK file")
+    args = parser.parse_args()
+
+    apk = args.apk
+    if not apk.exists():
+        print(f"[FAIL] file not found: {apk}")
+        return 2
+    if not apk.is_file():
+        print(f"[FAIL] not a file: {apk}")
+        return 2
+
+    size = apk.stat().st_size
+    print(f"[INFO] file={apk}")
+    print(f"[INFO] size_bytes={size}")
+    print(f"[INFO] sha256={sha256sum(apk)}")
+
+    if size <= 0:
+        print("[FAIL] APK is zero-byte.")
+        return 3
+    if size < 2 * 1024 * 1024:
+        print("[WARN] APK is very small (<2MB); verify this is expected.")
+
+    try:
+        with zipfile.ZipFile(apk, "r") as zf:
+            names = set(zf.namelist())
+    except zipfile.BadZipFile:
+        print("[FAIL] APK is not a valid ZIP container.")
+        return 4
+
+    required = {"AndroidManifest.xml", "classes.dex"}
+    missing = sorted(required - names)
+    if missing:
+        print(f"[FAIL] missing required entries: {', '.join(missing)}")
+        return 5
+
+    print("[OK] APK preflight passed.")
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())
+

docs/juzi/browserstack-trace-runbook.md

@@ -0,0 +1,36 @@
+# BrowserStack Trace Runbook (Issue #2994)
+
+## Objective
+Produce maintainers-grade evidence for where RCS setup fails, without fake success paths.
+
+## Steps
+1. Start a fresh BrowserStack Android session.
+2. Install the test APK once.
+3. Open Google Messages and trigger RCS setup flow.
+4. Open Developer Tools > Logcat.
+5. Set app/package filter to `org.microg.gms`.
+6. Keep logs running while reproducing setup state changes.
+7. Export/copy log text to a local file (example: `rcs_run_01.log`).
+
+## Local analysis
+Run:
+
+```bash
+cd "/Users/wolaoposongwodediannao/Downloads/codex ai工作文件/ready_for_dispatch/microg_gmscore"
+bash docs/juzi/run_rcs_research_pipeline.sh /path/to/rcs_run_01.log docs/juzi/output
+```
+
+## What to share in PR
+- Device + Android version.
+- Google Messages version.
+- Whether SIM/carrier profile is present.
+- Output of `docs/juzi/output/rcs_report.md`.
+- Output of `docs/juzi/output/rcs_contracts.json`.
+- Output of `docs/juzi/output/rcs_patch_plan.md`.
+- Output of `docs/juzi/output/rcs_research_brief.md`.
+- Exact first blocking candidate `(token, code, detail)`.
+
+## Reject patterns to avoid
+- Claiming "Connected" with no trace-backed transition chain.
+- Any unconditional success parcel response.
+- Identity hardcoding that cannot be justified or reproduced.

docs/juzi/harvest_downloads_phase2.sh

@@ -0,0 +1,84 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+ROOT_DIR="$(cd "$(dirname "$0")/../.." && pwd)"
+JUZI_DIR="$ROOT_DIR/docs/juzi"
+DOWNLOADS_DIR="${1:-$HOME/Downloads}"
+INBOX_DIR="${2:-$JUZI_DIR/phase2_inbox}"
+OUT_DIR="${3:-$JUZI_DIR/phase2_submissions}"
+MIN_LOG_BYTES="${PHASE2_MIN_LOG_BYTES:-64}"
+
+mkdir -p "$INBOX_DIR" "$OUT_DIR"
+
+copied=0
+import_one() {
+  local src_log="$1"
+  local src_json="${2:-}"
+  local base size dest_log
+  base="$(basename "$src_log" .log)"
+  dest_log="$INBOX_DIR/$base.log"
+
+  case "$base" in
+    .*|*~) return 0 ;;
+  esac
+
+  size="$(wc -c < "$src_log" | tr -d ' ')"
+  if [[ "$size" -lt "$MIN_LOG_BYTES" ]]; then
+    return 0
+  fi
+
+  if [[ -f "$dest_log" && "$src_log" -ot "$dest_log" ]]; then
+    return 0
+  fi
+
+  cp "$src_log" "$dest_log"
+  if [[ -n "$src_json" && -f "$src_json" ]]; then
+    cp "$src_json" "$INBOX_DIR/$base.json"
+  fi
+  copied=$((copied + 1))
+}
+
+shopt -s nullglob
+for f in "$DOWNLOADS_DIR"/*.log; do
+  base="$(basename "$f" .log)"
+  import_one "$f" "$DOWNLOADS_DIR/$base.json"
+done
+
+for z in "$DOWNLOADS_DIR"/*.zip; do
+  z_name="$(basename "$z")"
+  z_lower="$(printf '%s' "$z_name" | tr '[:upper:]' '[:lower:]')"
+  case "$z_lower" in
+    *phase2*|*rcs*|*logcat*) ;;
+    *) continue ;;
+  esac
+
+  z_key="$(printf '%s' "$z_name" | tr -c '[:alnum:]._-' '_')"
+  z_marker="$INBOX_DIR/.zip_imported_${z_key}.stamp"
+  z_info="$(stat -f '%m:%z' "$z")"
+  if [[ -f "$z_marker" && "$(cat "$z_marker")" == "$z_info" ]]; then
+    continue
+  fi
+
+  tmp_dir="$(mktemp -d)"
+  if ! unzip -q -o "$z" -d "$tmp_dir"; then
+    rm -rf "$tmp_dir"
+    continue
+  fi
+
+  copied_before="$copied"
+
+  while IFS= read -r log_file; do
+    log_dir="$(dirname "$log_file")"
+    base="$(basename "$log_file" .log)"
+    import_one "$log_file" "$log_dir/$base.json"
+  done < <(find "$tmp_dir" -type f -name "*.log")
+
+  if [[ "$copied" -gt "$copied_before" ]]; then
+    echo "$z_info" > "$z_marker"
+  fi
+  rm -rf "$tmp_dir"
+done
+shopt -u nullglob
+
+echo "harvested logs: $copied"
+bash "$JUZI_DIR/process_phase2_inbox.sh" "$INBOX_DIR" "$OUT_DIR"

docs/juzi/issue2994-breakthrough-roadmap.md

@@ -0,0 +1,63 @@
+# Issue #2994 - Technical Breakthrough Roadmap
+
+## Goal
+Deliver a solution that is technically real (can be reproduced), not UI-level simulation.
+
+## Hard reality
+If RCS fails due server-side trust gates (carrier/Jibe policy + app integrity coupling), local binder stubs alone will never be sufficient.
+So the first breakthrough is not "force connected", but "pinpoint the first authoritative rejection point with proof".
+
+## Breakthrough Hypothesis
+The bottleneck is likely one of these:
+1. Contract mismatch between Google Messages and microG RCS/CarrierAuth service behavior.
+2. Provisioning dependency on upstream trust signal that is not satisfied in current environment.
+3. State machine regression where client remains in setup loop because one mandatory transition callback is missing.
+
+## Engineering strategy (what we can actually ship)
+
+### Phase A - Contract Witness (must-have)
+- Add precise binder-level tracing:
+  - interface token
+  - transaction code
+  - caller uid/pid
+  - call order + timestamp
+  - response mode (unavailable/passthrough)
+- Add blocker detector:
+  - if the same unhandled `(token, code, detail)` repeats, emit `blocker_candidate`.
+- Output a deterministic trace set from a real run.
+
+Success criteria:
+- We can produce a single ordered trace showing exactly where setup stalls.
+
+### Phase B - Compatibility Adapter (minimal, reviewable)
+- Implement only required transactions verified by Phase A.
+- No synthetic "all good" response.
+- Unsupported versions fail closed with explicit traceable reason.
+
+Success criteria:
+- No fake status path.
+- Behavior is contract-specific and version-scoped.
+
+### Phase C - Evidence Matrix (maintainer-grade)
+- Each run includes:
+  - device model + Android version
+  - Google Messages version
+  - SIM/carrier status
+  - key trace excerpt
+  - observed UI state
+- Include at least one negative path and explain why it fails.
+
+Success criteria:
+- Maintainers can reproduce and reason about acceptance/rejection on their side.
+
+## What not to do (auto-reject patterns)
+- Hardcoded IMEI/IMSI/device identity payloads.
+- Unconditional `STATUS_OK` parcel replies.
+- Bundling unrelated auth/system changes in the same PR.
+- Claiming end-to-end support without trace-backed evidence.
+
+## PR narrative that can win trust
+1. "We instrumented first, then implemented the minimum compatible path."
+2. "This revision does not fake provisioning success."
+3. "Here is the exact trace where setup blocks today, and here is the targeted adapter behavior for that point."
+4. "Known limits are explicit."

docs/juzi/issue2994-community-validation-template.md

@@ -0,0 +1,26 @@
+# Issue #2994 Community Validation Template
+
+Please post validation results in this exact format:
+
+```
+Device:
+ROM:
+Android:
+Carrier/Country:
+Google Messages version:
+microG build commit:
+
+Result:
+- RCS state (Connected / Setting up / Error):
+- Time to state:
+
+Top blocker evidence (if not Connected):
+- token:
+- code:
+- detail:
+- repeated:
+
+Log excerpt (10-30 lines):
+<paste here>
+```
+

docs/juzi/issue2994-deep-dive.md

@@ -0,0 +1,37 @@
+# Issue #2994 Deep Dive (RCS Bounty)
+
+## 1) What maintainers actually care about
+- Works on **locked bootloader** devices.
+- No dependency on **root/Magisk**.
+- Compatible with **current Google Messages**, not only one frozen old version.
+- Must survive **real-world verification**, not only local mock success.
+
+## 2) Why prior attempts are rejected
+- Returned local `STATUS_OK` without proving end-to-end provisioning semantics.
+- Hardcoded identity data (IMEI/IMSI/model) instead of a defensible compatibility path.
+- Missing reproducible evidence matrix (device, ROM, app version, network, SIM profile, logs).
+- Broad claims without clear failure boundaries and rollback behavior.
+
+## 3) Current branch risks to fix before trust-building
+- `RcsShimServices` must move from observation to contract completion one row at a time, otherwise it remains a diagnostic-only layer.
+- Earlier branch variants included identity hardcoding and static provisioning replies; those patterns must stay removed.
+- `IdentityFidoProxyActivity` changes are not directly tied to RCS provisioning acceptance criteria.
+
+## 4) Breakthrough direction (engineering, not theater)
+- Replace "success-forcing" behavior with **trace-first** architecture:
+  - Add a recorder for binder transaction token, code, call order, response latency, and explicit failure reason.
+  - Keep behavior deterministic and fail-closed when required dependency is absent.
+- Implement **compatibility mediation**, not identity spoofing:
+  - Route only known RCS service contracts.
+  - Preserve original parcel semantics where possible.
+  - Explicitly mark unsupported contract versions.
+- Add strict evidence artifacts:
+  - Device + ROM + Google Messages version + SIM/carrier + timestamp.
+  - Log excerpts that show state transition chain, not only one terminal string.
+
+## 5) Acceptance gates for a credible PR
+- No hardcoded personal/device identifiers.
+- No unconditional "STATUS_OK" responses.
+- No unrelated subsystem edits bundled into RCS PR.
+- Clear unsupported-scope statement.
+- Reproducible verification table with at least one physical-SIM validation path.

docs/juzi/issue2994-maintainer-comment-draft.md

@@ -0,0 +1,18 @@
+Hi maintainers,
+
+I reviewed the failed attempts on this bounty and I am adjusting the implementation strategy to be evidence-driven rather than mock-driven.
+
+For PR #3294, I am removing success-forcing behavior and focusing on a compatibility + tracing path:
+
+1. Binder contract tracing for RCS/provisioning calls (token, transaction code, call order, response semantics).
+2. Fail-closed behavior for unsupported contract versions (no fake `STATUS_OK` on unknown paths).
+3. A reproducible validation matrix (device, ROM, Messages version, SIM/carrier, logs).
+
+Before I finalize the next update, I want to align with your review expectations on three points:
+
+- Which concrete signals do you consider sufficient to prove real RCS readiness (beyond UI state text)?
+- For the bounty scope, is one fully documented modern-device success path acceptable as phase 1, followed by broader compatibility in phase 2?
+- Are there specific binder interfaces or state transitions you want explicitly logged in the first reviewable revision?
+
+I will keep the next revision narrow, testable, and directly tied to the acceptance criteria in #2994.
+

docs/juzi/issue2994-maintainer-new-angle-comment.md

@@ -0,0 +1,17 @@
+Maintainers,
+
+I think the key blocker in #2994 is being approached from the wrong angle.
+This does not look like a "single provisioning response" issue. It looks like a contract-completeness issue across the RCS + CarrierAuth binder boundary.
+
+Most previous attempts tried to force a terminal state. That hides the real blocker and fails under review.
+
+I am taking a different route:
+
+1. Instrument exact contract rows (`token`, `transaction code`, call order, caller uid/pid).
+2. Identify the first blocking row in the real flow.
+3. Implement only that row + direct dependencies, keep unknown paths fail-closed.
+
+No unconditional success stubs, no inflated compatibility claims.
+
+If this direction matches your expectations, I will post the first blocker row report in the PR and keep the next patch narrowly scoped to that contract.
+

docs/juzi/issue2994-maintainer-reply-now.md

@@ -0,0 +1,17 @@
+Thanks for the clear questions.
+
+Direct answers:
+
+1. No, I have not yet validated this on a physical SIM-equipped device running a microG-capable custom ROM.
+2. No, this patchset has not yet been validated end-to-end in that same carrier-backed physical environment.
+
+Current PR scope is Phase 1 only: protocol-layer isolation and deterministic binder-contract analysis.
+I am not claiming final carrier-backed RCS activation from this patchset yet.
+
+What this PR currently contributes:
+- binder instrumentation for RCS/CarrierAuth contract paths,
+- ranked blocker evidence from repeated unhandled rows,
+- minimal fail-closed patch iterations per `(token, code)` row.
+
+I want to keep this PR active and move directly into Phase 2 validation.
+If you share a preferred device/ROM matrix, I will align to it and report results in a structured format.

docs/juzi/issue2994-maintainer-research-comment.md

@@ -0,0 +1,23 @@
+Maintainers,
+
+For #2994, I am treating this as a contract-completeness research problem, not a UI-state workaround.
+
+Working hypothesis:
+- the setup loop is caused by one or more missing/incorrect binder contract rows at the RCS + CarrierAuth boundary.
+
+Method in this revision:
+1. instrument binder rows (`token`, `code`, caller package/uid/pid, handled/unhandled),
+2. detect repeated unhandled rows as `blocker_candidate`,
+3. rank blockers and patch only rank-1 row in the next iteration.
+
+I am intentionally not claiming end-to-end success in this step.
+The goal is to produce reproducible blocker evidence and a minimal patch target that can be reviewed objectively.
+
+Artifacts generated from a run:
+- blocker trace report
+- contract map JSON
+- next patch suggestion
+- research brief
+
+If this review direction is acceptable, I will post the first rank-1 blocker row and submit a narrow completion patch for that exact `(token, code)` pair.
+