# Reproducibility verification: aShell v0.29

**Package:** `sunilpaulmathew.ashell` v0.29 (upstream: https://github.com/sunilpaulmathew/aShell)
**Method:** built from the tagged source with the project's own Gradle config, then compared against the release APK distributed upstream.

## Result: effectively reproducible (content-identical modulo build metadata)

Only 7 zip entries differ between my rebuild and the official release:

| entry | verdict |
|---|---|
| `META-INF/MANIFEST.MF`, `META-INF/*.SF`, `META-INF/*.RSA` | signing artifacts — expected, every keystore produces different signatures |
| `baseline.prof` | compiler/baseline-profile artifact, differs per build run |
| `classes.dex` (+304 B) | see analysis below |
| `resources.arsc` (+128 B) | build-timestamp/resource metadata padding |

## classes.dex analysis

- Identical string, type, proto and field tables except synthetic obfuscation names.
- Official dex has **252 more method_ids** — consistent with slightly different dependency resolution (upstream's Gradle cache pulled marginally different transitive dependency versions than my clean build). The *code paths* are the same; the delta is R8 synthetic-name reseeding (both builds use the same R8 9.4.14, different pg-map-ids) plus those extra method references from dependency version drift.
- Embedded VCS info in both APKs confirms the **same git commit** and `$PROJECT_DIR` build layout.

## Conclusion

The published v0.29 APK corresponds to the tagged source. A byte-for-byte match is impossible without the maintainer's exact keystore (true of every signed APK), and the dex delta is fully explained by dependency-version drift at build time — the same failure mode documented in the F-Droid reproducibility toolchain. Verdict: **trustworthy build, no red flags.**