Rename leak signature to leak fingerprint

[pyricau]

The hash that identifies a leak was called its signature everywhere: Leak.signature and LeakTrace.signature, the Signature: line of a printed heap analysis, unreadLeakSignatures on the analysis-done event, the leak table's column, and the leak row in Shark Explorer. It's now called its leak fingerprint.

Why

Two problems with the word, both of which cost a newcomer time.

It's already taken, twice. In a Kotlin or Java codebase "signature" means a method signature, and on Android it also means the signature an APK is signed with. Both senses live in this repo — HprofRecord.methodSignatureStringId, COMPRESS_SIGNATURE in the JDWP bitmap reader, PNG_SIGNATURE, the notarization step of the release workflow, and the change log entry about a constructor's signature changing. So a reader meets three unrelated meanings of one word, and the leak one is the odd sense out.

It never said what the hash is for, which is that two leaks with the same one are caused by the same bug. "Fingerprint" says content-derived identity, matches what Sentry calls the same concept, and collides with nothing here.

The hash itself doesn't change — same input, same SHA-1 — so a leak keeps the string it already had, and a bug report or a dashboard grouped by it still lines up across the upgrade.

Naming rule

Values are leakFingerprint, prose and user-visible text say "leak fingerprint", and the function names that already say Leak take ByFingerprint. So nothing reads leak.leakFingerprint or retrieveLeakByLeakFingerprint.

Breaking changes

Was	Is
LeakTrace.signature	LeakTrace.leakFingerprint
Leak.signature (and both subclasses)	Leak.leakFingerprint
HeapAnalysisSucceeded.unreadLeakSignatures	unreadLeakFingerprints
Signature: <hash> in printed output	Leak fingerprint: <hash>
"…with the same signature"	"…with the same leak fingerprint"

unreadLeakFingerprints is in leakcanary-android-core's ABI, the contract AGENTS.md says to break only as a last resort — flagging it rather than assuming it's fine. The ABI diff is exactly these five accessors and nothing else.

Database

The leak.signature column becomes leak.fingerprint, mirroring how the old schema named the column after the concept and the index after both (leak_signature → leak_fingerprint). ALTER TABLE RENAME COLUMN needs SQLite 3.25, i.e. API 30, so a version 26 migration copies the table over — create, copy, drop, rename — rather than recreating the database, which would throw away the user's stored leak history.

DatabaseMigrationTest upgrades a committed v24 database and then reads it back, so it covers this. It passes on API 24 and on API 36 — either side of the SQLite version where ALTER TABLE RENAME started rewriting other tables' foreign key clauses, which is the failure mode this migration is shaped to avoid.

The standalone leakcanary-app's SQLDelight schema is renamed too. It has no migration files, which is unchanged by this.

Left alone

• Every unrelated sense of the word: method signatures (methodSignatureStringId, FixedWindowCallback, ByteArrayTimSort), code signing (the release workflow and its doc), the JNI descriptor COMPRESS_SIGNATURE, PNG magic bytes, EqualsOnSignatureLine in the detekt config, and the // TODO Enforce package signature in LeakUiAppClient.
• Released change log entries. Versions 2.0, 2.1 and 3.0-alpha-3 describe an API that was called signature at the time; rewriting them would make them claim otherwise. Only the ## Unreleased section is updated.

Verification

• ./gradlew build — green, which includes checkKotlinAbi and detekt.
• ./gradlew :leakcanary:leakcanary-android-core:connectedDebugAndroidTest — 27 tests green on API 36, and the 7 DatabaseMigrationTest tests green on API 24 as well.

🤖 Generated with Claude Code