Repository navigation
RCS: consolidated Constellation/Asterism hardening for #2994 - #3808
Chess-Debug wants to merge 78 commits into
Conversation
…nsent request semantics Incorporates two commits from keeltrace that fix the automatic-consent fallback in VerifyPhoneNumber.kt: - fix(constellation): align automatic RCS consent request - test(constellation): cover automatic RCS consent semantics Co-Authored-By: keeltrace <keeltrace@users.noreply.github.com> Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Assemble the ordered PDU parts from a single SMS_RECEIVED broadcast before matching and buffering the logical message. Reject missing parts and keep the first available sender. Co-authored-by: Codex <codex@openai.com>
Cover multipart ordering, invalid or missing parts, and single-part/null-sender behavior. Co-authored-by: Codex <codex@openai.com>
Assemble ordered PDU parts from a single SMS_RECEIVED broadcast into one logical message before buffering and matching. Previously each PDU was treated as a separate ReceivedSms, so a challenge split across segments could never satisfy a pending match as one body. Also rejects empty broadcasts and broadcasts with any missing body part. Single-part behavior is unchanged. Co-authored-by: HumbleDrummer <HumbleDrummer@users.noreply.github.com>
Transplant the exact file contents from Anusha0501's naormeit#4 onto the current integrated RCS base 276523b without replacing the multipart MT-SMS work already present there. Original-Commit: d2a6b75 Source-PR: naormeit#4 Authorship/implementation credit: Anusha0501 This is a provenance-preserving integration commit, not a re-claim of the contributor's work.
Port only the non-overlapping KeelTrace hardening exercised by the private Foundragon validator: explicit signing failure, null-or-empty Gaia ID recovery, and the follow-up Gaia logging repair. Original-Commits: - b0db179 - 57e43af - 3aacca3 Source-PR: naormeit#6 Authorship/implementation credit: KeelTrace Consent commits from that PR are intentionally not re-imported because the Anusha integration already supplies the overlapping consent resolver path.
Use the pre-API-23 AccountManager.get(Context) accessor and declare GET_ACCOUNTS in the DroidGuard core manifest, matching the permission contract already used by Constellation. Preserve the existing SecurityException fail-closed behavior.
…ening Promotes the exact Foundragon RC1 delta validated in private CI. Preserves prior contributor provenance and keeps Samsung CompositeToken compatibility separate from Google Constellation IID semantics.
A duplicate mapOf key caused the later Messages entry to replace the earlier one at runtime. Consolidate the four intended flags under one key and retain a JVM regression proving the complete flag set.
|
@Chess-Debug — thanks for the consolidation work and for preserving contributor attribution. For the record: #3784 is the originating PR for this RCS implementation, submitted before this PR existed. The commit history in #3808 builds directly on naormeit:rcs-bounty-2994 and carries my commits forward intact. All the follow-up work from @keeltrace, @Anusha0501, and @HumbleDrummer was developed on top of #3784 and first merged into my branch. I'm raising this here so maintainers are aware of the submission order before deciding which PR to merge or how to handle the bounty at #2994. I'm happy to coordinate on whichever approach the maintainers prefer, but the bounty credit should reflect that #3784 was the prior submission this work is built on. |
Keep the RCS-only consent-version classification in one place so the fast-path and client guard cannot silently drift. This also classifies the Samsung unfreeze version as RCS-only without enabling it as a generic fast path, and adds regression coverage for the complete RCS-only set.
For the record: the Foundragon team fully acknowledges that #3808 inherits its original RCS implementation lineage from #3784, and that contributor attribution and commit ancestry have been preserved accordingly. It is equally important, however, to distinguish source provenance from the technical state of the implementation that was inherited. During the consolidation and verification work performed on top of #3784, we identified and corrected a number of issues that were still present in the inherited implementation. This included not only larger behavioral defects, but also several small-looking inconsistencies which, at runtime, affected materially important correctness boundaries. Among the work completed in #3808:
A significant part of this work also involved reducing duplicated or fragmented decision logic, consolidating predicates that had begun to diverge, and replacing implementation-by-accumulation with explicit invariants and regression tests. Some of these changes are only a few lines of code; their importance lies in the runtime boundary they protect rather than their diff size. So, for the record, there is no disagreement regarding where the initial implementation originated. #3784 established the originating implementation line. #3808 preserves that history, then performs the additional consolidation, correctness work, hardening, regression coverage, and runtime-boundary cleanup required to turn that inherited line into the implementation currently being proposed for integration. Maintainers can therefore evaluate provenance and final technical state as two separate, fully visible parts of the same history. Foundragon Team |
|
I opened a narrow collaboration follow-up for the IMS Phenotype provider path: Chess-Debug#4 #3808 already contains The follow-up is exactly 3 files (+43/-1), directly on the current #3808 head. It has assertion-level RED->GREEN coverage, Release + Debug tests, a full release assembly, and a locked/green Pixel 3 physical A/B:
The PR explicitly preserves the #3385/#3808 lineage and does not claim this alone changes provisioning outcome or solves #2994. The demonstrated result is provider delivery of the already-existing flag. |
) Replace DummyService API_DISABLED stub with a real play-services-constellation implementation: AIDL API surface, ConstellationApiService binder, gRPC/Wire client, TS.43/MO/MT SMS verifiers, IID token signing, and settings-backed PNV state. Adapted from high-signal open work toward microg#2994 (notably @opstic microg#3359 and hardening consolidated in microg#3808/microg#3784). Not a claim of end-to-end RCS on device.
Implement play-services-asterism with AIDL surface and AsterismApiService for get/setAsterismConsent and getIsPnvrConstellationDevice, including fail-closed RCS consent semantics and Samsung composite-token helpers. Adapted from @opstic microg#3360 with hardening from microg#3808/microg#3784. Depends on the Constellation module for shared RPC/client pieces.
Port the alternate com.google.android.gms.auth.APP_CERT intent filter from @paulcakeface microg#3815 so Messages/clients that bind that action can reach AppCert. Constellation SpatulaHeaderProvider tries the classic be.appcert action then APP_CERT. Add AppCertManager Spatula fallback unit coverage aligned with microg#3808.
Document implemented RCS stack, gap vs microg#3360/microg#3808, build/test commands, logcat filters, and evidence Ayush must capture for BountyHub. Honest: still needs on-device E2E; no PR ready from this commit.
9 participants
Summary
This PR consolidates and hardens the existing RCS implementation work for #2994.
It builds on the existing #3784 integration line while preserving contributor attribution, and adds/finalizes:
RCS_CONSENTfast-path handlingX-Goog-SpatulasupportAccountManagerlint correctnessThe branch has been synchronized with current upstream master:
4c74e5acb79479004428be755547432294639878The only source overlap during the final upstream merge was
PhenotypeService.kt; upstream Translate configuration changes and the validated Google Messages/RCS configuration were both retained.Final pre-PR verification catch
The final integration sweep caught a silent runtime configuration bug in
PhenotypeService.kt.The Google Messages package key was present twice in the Kotlin
mapOf. Because duplicate keys use last-write-wins semantics, one flag group silently replaced the other even though the project still compiled and linted successfully.A pre-fix regression reproduced the loss: only 2 of the 4 intended Messages flags were retained.
The duplicate entries were consolidated into a single package entry containing all four flags, and the same regression then passed.
Fix commit:
0e089118b7c247d0e6ecf37703d76b7350d7e0ffBEFORE → AFTER verification:
35118311199— SUCCESSFinal verification
Pre-upstream-sync validation:
35137092919Upstream synchronization merge:
6c22d11f91943d22119b87cafa875ecf86ab6093Final exact validation head:
77932be0fa7fae8b1958be9515489342399fe9faFinal upstream-synchronized matrix:
35140936359— SUCCESSAttribution
This PR intentionally preserves the provenance of the work it consolidates.
It carries forward the #3784 line and its credited contributors, including:
@opstic
@br413
@camilo-12ch
@paulcakeface
@nwinkelman2
@naormeit
Additional source incorporated during the hardening/integration work includes:
@Anusha0501
d2a6b75bbcd79b7aa59dbbaa74953b375fd287d4@keeltrace
b0db17953aa29bc54a6301f8c3578801588579b057e43afce69618549ca65e764d939f5647eb415d3aacca36dd887c396ef4fd2b65037a645c107c03The multipart MT-SMS work is retained from its existing contributor lineage, and the AppCert/Spatula Binder approach follows the work documented by @juliushill42 and the existing RCS integration discussion.
Acceptance boundary
This PR does not claim physical acceptance that has not been performed.
Still requiring real-device validation:
The source, regression, build and lint gates described above are complete and green.
Refs: #2994, #3784