# downloads/vendor-reference/ — NOT RELEASES. DO NOT INSTALL ON KIOSK-X CABINETS.

Everything in this prefix is a **third-party / upstream vendor artifact kept for reference
and comparison only**. Nothing here is built, signed, or released by Intelliverse X, and
nothing here should ever be handed to a technician or a manufacturer as an installable build.

The APK below **is** linked from the downloads page — at the foot of it, in a panel headed
"Not a release — vendor reference material", one disclosure click in, with no download button.
That listing does not make it installable, and it is not an endorsement that it is safe to
put on a cabinet. If you followed that link here, the panel you came from was telling you the
truth.

Real Kiosk-X releases live one level up, in `downloads/`.

---

## reyeah-jd-vapetm-1.0.98-d532bb53c9aa.apk

| | |
|---|---|
| SHA256 | `d532bb53c9aa52e4e3ab0a8a4aa6fb12283bdb0f8d314082634eaadb487bbc0e` |
| Size | 25,283,633 bytes (24.1 MiB) |
| Package | `com.ruiye.jd` |
| versionName / versionCode | `1.0.98` / `3` |
| App label | `Vapetm` |
| Upstream build stamp | `reyeah-jd-v1.0.98_260626_c13ee8c_beta.apk` |
| Signing cert DN | `CN=lijinshou, OU=ruiye, O=ruiye, L=guangzhou, ST=guangdong, C=CN` |
| Signing cert SHA256 | `d2581b304ad3c38c9b16e68438281fa071c41e1d99b6241ec1d517a3ee63d8e6` |
| Backend | `https://sapi.vapevendingsoftware.com`, `tcp://mq.vapevendingsoftware.com` |
| Added | 2026-08-18 |

### What this actually is

This is the Reyeah / Ruiye (Guangzhou) OEM vending application, provisioned for **a different
operator** — a vape vending company trading as "Vapetm". It is the manufacturer's own beta
build, signed with the manufacturer's own key. It is not ours, it was never ours, and it is
not a newer version of anything we ship.

It is kept here because it is the **pristine upstream** of the app we do ship. See
"Relationship to our Reyeah build" below.

### Why it must never be installed on a Kiosk-X cabinet

**It carries the same package name as our own Reyeah build (`com.ruiye.jd`) but is signed with
a different key.** That combination is the hazard, and it bites in stages:

1. **It will not install over ours.** Android refuses a package-name match with a mismatched
   signing certificate — the installer fails with `INSTALL_FAILED_UPDATE_INCOMPATIBLE`. So a
   technician who tries this on a live cabinet hits an error, not a silent success.

2. **Even with a matching signature it could never be a legitimate update.** Its versionCode
   is **3**; ours is **122**. Android will not install a lower versionCode over a higher one,
   so this would be refused as a downgrade regardless of signing. There is no configuration in
   which this file is an upgrade to a Kiosk-X cabinet.

3. **The obvious workaround is the damaging part.** The natural response to those errors is to
   uninstall the existing app and install this one cleanly. Uninstalling our build **wipes the
   kiosk's local configuration and drops the machine off our control plane** — it stops
   reporting to `api.kiosk-x.ai` / `mq.kiosk-x.ai` and has to be re-provisioned on site.

4. **And if it does run, it reports to a third party.** This build's endpoints are
   `sapi.vapevendingsoftware.com` and `tcp://mq.vapevendingsoftware.com`. A cabinet running it
   is talking to another company's backend, not ours.

If you are holding this file because you want to update a Kiosk-X machine: **stop, and get a
real build from `downloads/`.**

### Relationship to our Reyeah build (`downloads/reyeah-vending-kioskx-1.2.2-*.apk`)

Our shipped Reyeah 1.2.2 **is this same upstream build**, re-pointed and re-signed. Both APKs
embed the identical upstream build stamp `reyeah-jd-v1.0.98_260626_c13ee8c_beta.apk`. The
differences between this file and our 1.2.2 are:

| | This file (upstream) | Our 1.2.2 |
|---|---|---|
| HTTP backend | `sapi.vapevendingsoftware.com` | `api.kiosk-x.ai` |
| MQTT broker | `mq.vapevendingsoftware.com` | `mq.kiosk-x.ai` |
| Signing key | ruiye / Guangzhou (`d2581b30…`) | Kiosk-X Vending (`d76b4ae5…`) |
| Signature block | `META-INF/CERT.*` | `META-INF/KIOSKX.*` |
| Kiosk-X classes | none | `com/kioskx/MachineQrDialog`, `com/kioskx/OtaIntegrity` |
| Version stamp | `1.0.98` / `3` | `1.2.2` / `122` |

Everything else matched: identical permission set, identical native libraries, and an
identical set of embedded URLs apart from the one backend substitution. The remaining
file-listing differences are only resource-qualifier repackaging (`res/anim-v21/` here vs
`res/anim/` in ours).

Note that our `1.2.2` version number is **ours, not the vendor's** — upstream is still
`1.0.98`. Do not read our version numbers as upstream version numbers, and do not let the `98`
read as newer than `1.2.2`: it is older, and the versionCodes (3 against 122) are the
unambiguous ordering.

### Security review performed before hosting

Checked deliberately, given the earlier `kiosk-x-operator` supply-chain incident:

- **No dynamic code loading** in either build — no `DexClassLoader`, no
  `InMemoryDexClassLoader`, no runtime dex fetch. None of the obfuscated-loader pattern.
- **No extra permissions** relative to our own shipped build.
- **Native libraries** are the expected vendor set: ijkplayer / Aliyun player, Tencent Bugly
  crash reporting, and `libserialport.so` for VMC control.
- Signature verifies cleanly under v1 and v2 schemes, single signer.

Conclusion at the time of hosting: this appears to be a **legitimate manufacturer build**,
not a tampered one. It is withheld from `downloads/` because it belongs to another operator
and collides with our package name — not because it is believed to be malicious.

One caveat worth knowing: both this build and ours ship **LeakCanary**, a debug-only memory
leak library, and the upstream stamp is marked `beta`. That is an upstream trait we inherited,
not something specific to this file.