fix(android): don't block APK update when signing info is unavailable#71
Merged
Merged
Conversation
verifyAPK hard-failed with SIGNATURE_UNAVAILABLE whenever PackageManager.getPackageArchiveInfo(...) returned null signers for the downloaded APK. On some OEM ROMs (Huawei/EMUI on Android 9-10) and for large APKs the platform cannot re-parse the archive's signing block and returns null even for a perfectly valid, untampered APK, while the installed app's signers read back fine. That asymmetric "can't read the archive's signers" was treated as "forged", bricking the in-app update (observed: 6.1.0 -> 6.3.0, HUAWEI SEA-AL10, Android 10, ~194MB APK -> "安装包完整性检查失败 - 安装不安全"). This signing-cert cross-check is defense-in-depth only: verifyASC already proves the bytes are the authentic OneKey APK via GPG + SHA-256, and Android's PackageInstaller re-verifies the signing certificate at install time. So a genuine certificate MISMATCH is still hard-failed, but when the signers are simply unavailable we now just log it and silently skip the check instead of throwing. Normal devices are unchanged. Claude-Session: https://claude.ai/code/session_01NwuZPQd7xBE8S7KFtdkT9Y
e50e815 to
93b9c4d
Compare
Add a selectedIcons prop end-to-end so UIKit owns the bottom-tab selection visual instead of a JS round-trip: - codegen spec + .mm prop bridge for selectedIcons - Swift loadSelectedIconsFromSources / bakeTint(.alwaysOriginal) / selectedImage so iOS 26 Liquid Glass stops washing icons to one tint and the focused (solid) artwork swaps natively with the selection animation - TabView passes unfocused icons as icons and focused icons as selectedIcons on iOS; Android keeps the focusedKey-driven array (no-op setSelectedIcons) - activeTintColor/inactiveTintColor didSet rebuild so baked tints follow theme - updateSelectedTab skips the redundant performWithoutAnimation re-set when UIKit already moved the selection (keeps the native capsule animation) Ported from the app-monorepo patch-package patch (OK-54175). Claude-Session: https://claude.ai/code/session_019KatVf3hQYnB4oESVYQ8AL
ByteZhang1024
approved these changes
Jun 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
PM report: upgrading the Android app 6.1.0 → 6.3.0 fails at the last verification step with 「安装包完整性检查失败 - 安装不安全」 (APK integrity check failed — unsafe to install).
Device: HUAWEI SEA-AL10, Android 10 (API 29), EMUI, APK ~194 MB.
Root cause (proven from logs)
The update pipeline is
download → downloadASC → verifyASC → verifyPackage. The first three steps passed:verifyASCGPG-verifies the detached.ascandsecureCompares the downloaded file's SHA-256 against the signed hash. Passing it proves the 194 MB file on disk is byte-for-byte the authentic OneKey APK — corruption / bad download is ruled out.It then died in
verifyAPK:PackageManager.getPackageArchiveInfo(apkPath, GET_SIGNING_CERTIFICATES)returned null signers for the archive, while the installed app's signers read back fine. On some OEM ROMs (Huawei/EMUI on Android 9–10) and for large APKs, the platform cannot re-parse the archive's signing block and returns null even for a valid, untampered APK. The old code treated this asymmetric "can't read the archive's signers" identically to "signature is forged" and hard-threwSIGNATURE_UNAVAILABLE, blocking a legitimate update.Why it's safe to skip
This signing-cert cross-check is defense-in-depth only:
verifyASCalready proved authenticity via GPG + SHA-256 beforeverifyAPKruns.INSTALL_FAILED_UPDATE_INCOMPATIBLE.So failing the whole update because a redundant check couldn't read the signers is strictly worse than letting the OS make the final call.
Change
Minimal: in both
verifyAPKbranches (API ≥ PGET_SIGNING_CERTIFICATES, and legacyGET_SIGNATURES), when the signers are null/unavailable, just log it at info level and skip the check instead of throwingSIGNATURE_UNAVAILABLE.SIGNATURE_MISMATCH.Testing notes
softwareUpdateResultevents withfailedStep=verifyPackage+SIGNATURE_UNAVAILABLEand check whether it's Huawei-only or all Android ≤10; and compareapksigner verify -v --print-certsv1/v2/v3 scheme flags between the 6.1.0 and 6.3.0 release APKs.https://claude.ai/code/session_01NwuZPQd7xBE8S7KFtdkT9Y