RESEARCH PROGRAM / PRE-LAUNCH

Two evidence-reviewed candidates. More questions still have to earn a page.

The signing-history and cross-channel identity pages have passed evidence review. Every other item still identifies what the related download site already publishes and the new evidence required here.

01 / TRACK

Dataset study

Evidence-reviewed candidate

Android signing lineage and key rotation

Question: Across historical releases, which update paths keep one signer, use a valid key-rotation lineage, or break continuity?

2113 Apps already covers: 2113 Apps publishes one current signer for each measured artifact and a current-release signing summary.

Required increment: Collect historical artifacts and classify stable keys, v3-family lineage-proven rotations, first-party announced key replacements without verified lineage, distribution-channel signer changes, unexplained changes, and missing evidence separately.

New collection: Historical APK digests, signer certificates, v3 proof-of-rotation lineage, first-party key notices, version/channel metadata, installation consequences, and an exception review log.

Read the measured candidate

Evidence-reviewed candidate

Cross-channel Android build identity

Question: For the same package and version, how do developer, GitHub, F-Droid, and repository builds differ?

2113 Apps already covers: 2113 Apps measures one selected distribution source for each current package.

Required increment: Acquire matched same-version artifacts from two or more channels and compare hash, signer, manifest, native libraries, and documented reproducibility without treating a difference as tampering by default.

New collection: Paired artifacts, source-commit links, build metadata, signer/lineage records, and upstream explanations for expected differences.

Read the measured candidate

Core candidate

Static capability versus observed network activity

Question: Where do manifest permissions and embedded libraries agree—or fail to agree—with controlled runtime observations?

2113 Apps already covers: 2113 Apps already aggregates permissions and static tracker-library indicators.

Required increment: Add a documented runtime network test on a declared sample and reconcile observed endpoints with source code while preserving encrypted-traffic and coverage limits.

New collection: Versioned test builds, device/emulator state, capture procedure, endpoint observations, source references, negative controls, and unobserved-path caveats.

Core candidate

16 KB alignment of 64-bit native libraries

Question: For arm64-v8a and x86_64 libraries, which APKs are fully aligned, run through 16 KB backcompat mode, or fail in a controlled 16 KB runtime?

2113 Apps already covers: 2113 Apps reports bundled ABIs and mentions Termux's 16 KB work, but does not systematically measure 64-bit ELF, ZIP, or GNU_RELRO alignment.

Required increment: Apply the official LOAD, ZIP, and GNU_RELRO rules to 64-bit libraries, then keep static alignment, observed backcompat mode, and observed runtime failure as separate results.

New collection: 64-bit native libraries, LOAD and GNU_RELRO program headers, APK ZIP alignment, tool versions, package/version identity, backcompat-mode state, and selected runtime observations.

02 / TRACK

Comparison

Conditional candidate

Minecraft launcher artifact-to-source paths

Question: Can each launcher release be connected to a source revision, signer history, bundled runtime set, and updater path?

2113 Apps already covers: 2113 Apps already compares FCL, Zalith, Amethyst, and Mojo features, device requirements, sizes, and current APK measurements.

Required increment: Compare release artifacts with source revisions and bundled payloads across versions; map signer changes and updater endpoints instead of repeating the feature table.

New collection: Historical artifacts, release commits, signer/lineage records, bundled runtime inventories, updater endpoints, and unresolved source-to-binary gaps.

Conditional candidate

Root-stack component provenance graph

Question: Which APKs, modules, ZIPs, frameworks, and updater endpoints form a selected root/module installation chain?

2113 Apps already covers: 2113 Apps already has an LSPosed installation guide, APatch and root-solution pages, and some current signature checks.

Required increment: Build a versioned dependency graph with artifact-level hashes, signers, v3 lineage, updater endpoints, and changes between releases; do not repeat installation instructions.

New collection: Pinned framework/module releases, APK and ZIP digests, signer/lineage data, dependency edges, updater configuration, and per-version change records.

Conditional candidate

YouTube Music clients: runtime dependency map

Question: Which first- and third-party services are contacted during the same controlled tasks, and which source paths explain them?

2113 Apps already covers: 2113 Apps already compares features, online sources, current signatures, permissions, and selected login behavior.

Required increment: Run the same documented task sequence across selected clients and reconcile observed endpoints with authentication, lyrics, update, telemetry, and media-source code paths.

New collection: Versioned builds, identical task scripts, runtime captures, endpoint ownership notes, source references, and untested-path limitations.

03 / TRACK

Case study

Conditional candidate

Kreate historical release chain

Question: Do historical and cross-channel Kreate artifacts preserve a traceable signer and source-to-release path?

2113 Apps already covers: 2113 Apps already publishes Kreate's current package/build, source, file hash, signer, permissions, trackers, ABIs, and recent release table.

Required increment: Retain this only if historical artifacts or matched channel builds support a per-version signer/lineage and binary-difference record that 2113 Apps does not publish.

New collection: Historical or paired Kreate artifacts, signer/lineage records, source commits, build notes, and explained binary differences; otherwise merge into the signing studies.

Conditional candidate

Disable Target API Block behavior validation

Question: Under declared Android and target-app versions, which compatibility changes does the module alter and where does it fail?

2113 Apps already covers: 2113 Apps already documents the module's source mechanism, current artifact identity, signature, permissions, size, and static scan.

Required increment: Keep a standalone page only if controlled before/after tests produce reproducible state, logs, and failure boundaries beyond the existing source explanation.

New collection: Pinned module and target-app versions, Android environments, before/after compatibility state, logs, reproducible steps, and negative results.

Conditional candidate

APatch update-chain changes

Question: How do manager artifacts, updater configuration, signer lineage, and component boundaries change across releases?

2113 Apps already covers: 2113 Apps already publishes the current APatch artifact, root comparison, and a current signature match.

Required increment: Publish separately only if historical manager artifacts and updater records answer a narrower change-over-time question; otherwise use APatch as one case in the root-stack graph.

New collection: Historical manager artifacts, signer/lineage data, updater responses/configuration, component versions, and documented boundary changes.

Conditional candidate

Fossify as a no-network negative control

Question: What does a controlled runtime capture show for apps without the INTERNET permission, including OS-mediated activity around them?

2113 Apps already covers: 2113 Apps already shows that eleven Fossify packages share one signer, request no INTERNET permission, and match no known tracker signature.

Required increment: Use selected Fossify builds only as a negative-control case in the runtime study; do not publish another suite summary unless the test yields a distinct, carefully scoped finding.

New collection: Pinned builds, clean test environments, runtime captures, OS-versus-app attribution, source review, and explicit coverage limits.

04 / TRACK

Tool

Conditional candidate

Historical APK hash, certificate, and lineage lookup

Question: Can an exact local digest or certificate be matched to a dated historical or cross-channel research record?

2113 Apps already covers: 2113 Apps already exposes current hosted-artifact records and current hashes.

Required increment: Index the new multi-version, paired-channel, and v3 lineage records produced by the research program; a current-only clone of 2113 Apps data is not eligible to launch.

New collection: Versioned research datasets, exact-match indexes, provenance and collection dates, lineage links, and a fixed no-safety-verdict notice.