fix(android): sign release APK v2+v3 only (drop invalid v1 JAR signature) #111

Merged
funman300 merged 1 commits from fix/apk-signing-v1-obtainium into master 2026-06-25 18:16:58 +00:00
Owner

Problem

The released APK installs via direct sideload but fails in Obtainium at install with:

RangeError (length): Invalid value: valid value range is empty: 0

Root cause: the apksigner step relied on auto scheme selection and produced an APK carrying an invalid v1 (JAR) signatureMETA-INF/*.SF/*.RSA present but failing v1 verification (apksigner reports v1 scheme: false, while v2/v3 verify). Android installs it fine via v2/v3, but Obtainium parses the legacy v1 certificate at install time, gets an empty cert list, and crashes. That matches the symptom exactly: adds fine (Gitea API only) but fails on install (APK parse).

Fix

minSdk is 26, so v1/JAR signing is unnecessary. Sign explicit v2+v3 only (what modern Android tooling produces for minSdk >= 24), pass --min-sdk-version 26, and add a post-sign guard that fails the build if any META-INF v1 signature files remain. Verified locally: re-signing with these flags yields a clean, aligned, valid v2+v3 APK with no stray cert files.

Needs a follow-up patch release (v0.40.1) to publish a re-signed APK.

🤖 Generated with Claude Code

## Problem The released APK installs via direct sideload but **fails in Obtainium at install** with: ``` RangeError (length): Invalid value: valid value range is empty: 0 ``` Root cause: the `apksigner` step relied on auto scheme selection and produced an APK carrying an **invalid v1 (JAR) signature** — `META-INF/*.SF`/`*.RSA` present but failing v1 verification (`apksigner` reports `v1 scheme: false`, while v2/v3 verify). Android installs it fine via v2/v3, but Obtainium parses the legacy v1 certificate at install time, gets an empty cert list, and crashes. That matches the symptom exactly: *adds fine* (Gitea API only) but *fails on install* (APK parse). ## Fix minSdk is 26, so v1/JAR signing is unnecessary. Sign **explicit v2+v3 only** (what modern Android tooling produces for minSdk >= 24), pass `--min-sdk-version 26`, and add a post-sign guard that fails the build if any `META-INF` v1 signature files remain. Verified locally: re-signing with these flags yields a clean, aligned, valid v2+v3 APK with no stray cert files. Needs a follow-up patch release (v0.40.1) to publish a re-signed APK. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
funman300 added 1 commit 2026-06-25 18:16:57 +00:00
The apksigner step relied on auto scheme selection, which produced an APK
carrying invalid v1 (JAR) signature files: META-INF/*.SF and *.RSA were
present but failed v1 verification (apksigner reports `v1 scheme: false`
while v2/v3 verify). Android installs such an APK fine via v2/v3, but
Obtainium parses the legacy v1 certificate at install time, gets an empty
cert list, and crashes with:

  RangeError (length): Invalid value: valid value range is empty: 0

This is why the app adds fine in Obtainium (Gitea API only) but fails on
install (APK parse). minSdk is 26, so v1/JAR signing is unnecessary —
sign explicit v2+v3 only (matching modern Android tooling for minSdk >= 24)
and pass --min-sdk-version 26. Adds a post-sign guard that fails the build
if any META-INF v1 signature files remain.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
funman300 merged commit 26283b5478 into master 2026-06-25 18:16:58 +00:00
funman300 deleted branch fix/apk-signing-v1-obtainium 2026-06-25 18:16:58 +00:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: funman300/Ferrous-Solitaire#111