Source Identity

Clone and pin the Android source

Reproducible work begins with source identity. EdgeORE's marketing site and Android app are separate projects, and a website archive is not an installable dApp. Clone the Android repository when you intend to build the APK. Clone or extract the website when you intend to work on presentation and documentation. Keeping those workspaces separate prevents a React preview from being described as a native runtime.

Pin before building

Choose the exact source revision associated with the candidate you are testing. The historical recorded candidate uses d675002bd701. Later commits may contain evidence-only changes or actual fixes. A branch name such as main is a moving reference, so record its full resolved hash before starting the gate. A wallet-fix APK should be identified by its own commit and hash, not by the historical candidate's stamp.

git clone https://github.com/CodesbyFebin/EdgeORE.git
cd EdgeORE
git status --short
git rev-parse HEAD
git switch --detach d675002bd701

These commands create a new clone and select the historical candidate. A detached checkout is useful for inspection, but new changes should go on a named branch. If an existing checkout has uncommitted work, inspect it before switching revisions. Do not erase that work merely to make the command sequence look clean. A fresh clone is usually the clearest way to reproduce a gate without disturbing ongoing development.

Distinguish three identities

Source identity is the Git commit. Binary identity is the APK's full SHA-256 and signing certificate. Runtime identity is the package and version observed after installation, ideally including About's source stamp. All three belong in the evidence. A file can have the right name and still contain an older build. A device can have a new APK on disk while continuing to run an older installed package.

The historical recorded hash is 6ee17a3cac0c363b130caa2523118e068b3449f9f1d1ac49b449f3dae3f6a4e6. Use that only for the exact recorded file. A local rebuild may produce another hash because of the debug signing key or build environment. Record that new hash and qualify that binary rather than borrowing the old one. File hashes identify bytes; they do not judge which build is better.

Inspect branches without mixing claims

The diagnostic wallet branch improves error visibility. The experimental on-device AI branch adds a separate runtime direction. Neither becomes part of the recorded candidate just because it exists on GitHub. Read the diff, dependency changes, qualification output and runtime limitations for the branch you actually build. Do not combine the test total from one branch with the APK size or screenshots from another.

A useful review manifest includes repository URL, source revision, branch when relevant, candidate filename, build command, UTC time and known environment limitations. It can also name a base revision for a feature branch. This makes a future regression investigation possible without searching a long chat history. The manifest is a small artifact with more lasting value than another claim that everything is done.

Complete the exercise

Build from a pinned checkout, calculate the APK hash and write a short manifest before installation. After launch, compare About with the manifest. Deliberately inspect an older candidate manifest and identify why its hash cannot be substituted. The expected lesson is that source equivalence, artifact equivalence and observed runtime behavior are related but distinct. A release note should make that relationship explicit instead of requiring a reviewer to infer it.

---

Wiki home · Qualification updates · Sources and credits