Reading Publicly Distributed LiteJam App Materials and Selecting an Android Test Device

Why the Android APK outranks the iOS binary, and what hardware the work actually requires

Project: LiteJam guitar client software and firmware
Document date: September 1, 2026
Companion document: LiteJam Bluetooth LE Protocol Capture and Analysis

Executive summary

Understanding the LiteJam BLE interface can proceed by observing the user's own guitar traffic or by reading publicly distributed companion-app materials with standard developer tools. Code reading is useful because it can show what an app can do rather than only what it happened to do during one session.

Provenance and scope: This document discusses only publicly distributed app packages, LiteJam's public websites and updater, and the user's own devices. It does not advocate or require bypassing encryption, authentication, access controls, firmware protection, device security, or private systems. LiteJam's public web clients ultimately made mobile-binary work unnecessary for the implemented LED controller.

Two public app-package formats were considered. A publicly distributed Android APK can be rendered into readable Java or Kotlin with the standard jadx developer tool. The iOS package format is less directly readable and was not needed because the Android materials and LiteJam's public web code offered the same relevant information more directly.

The controlling finding is that the LiteJam APK is obtainable on Windows without owning an Android device, from a mirror that carries this low-install app. Static analysis can therefore begin immediately with no hardware purchase.

An Android device remains worth buying, but for a different reason than originally assumed: it is a capture-iteration convenience, not a prerequisite. Android's Bluetooth HCI log reduces the per-capture cycle from roughly ten minutes on iOS to seconds, which matters because the differential comparison method depends on many repetitions. A used Pixel is the correct purchase; a tablet is not.

1. What each tool displays

The two public app-package formats differ in kind, not merely in degree.

Android — jadx. Android applications ship as Dalvik bytecode, a high-level, typed, class-structured format that retains method names, field names, and string constants. jadx renders a lawfully obtained public package into readable Java or Kotlin for ordinary compatibility research.

iOS — not used. Apple distributes compiled ARM64 machine code, which is less directly readable. Because LiteJam's public web clients and Android materials offered the relevant interface information openly, no iOS code conversion or protection bypass was necessary or pursued.

For identical protocol information, the Android path is not marginally easier. It is a different class of problem.

2. What static analysis provides that capture cannot

Four items justify the effort regardless of which binary is examined.

The serialization routine. The method that assembles the byte array passed to the BLE write call yields field order, widths, endianness, and constants directly — the answer that differential capture analysis only slowly triangulates.

Checksum and CRC algorithms. Differential comparison can identify that a byte is a checksum but may not identify which published algorithm is used. Reading a plainly available client function can answer that question directly.

The implemented command set. A switch over command opcodes in a publicly distributed client can enumerate the commands that client uses, including commands that may not appear in every user-interface session.

Handshake constants. If the guitar requires a challenge-response using a value compiled into the app, captures show an opaque exchange that cannot be reproduced. The binary shows the constant.

3. Why public web and Android materials were preferred

The iOS executable was not needed or examined. LiteJam's public web clients supplied directly readable JavaScript, and publicly distributed Android packages can be read with standard Android developer tooling. Those sources are clearer, easier to verify, and fully sufficient for compatibility work without interacting with platform protections.

4. Verified facts about the LiteJam Android app

Confirmed from the store listings on the document date.

Mirror availability was genuinely in doubt and had to be checked rather than assumed. Neither APKMirror nor APKPure carries this package; an application with roughly 3,200 installs falls below the threshold at which most mirrors bother to crawl. APKCombo does carry it, which is what makes the no-hardware path viable.

Two data-quality notes. AppBrain reports version 1.9.1 from April 2026 and is stale; the current release is 2.1.1. Match the inspected version to the observed version so ordinary release differences are not mistaken for protocol discrepancies.

Separately, the vendor's own setup instructions disclose the advertised Bluetooth device name, in the form Litejam RGB24. That removes any ambiguity about which peripheral in a scan is the guitar, both in nRF Connect for Mobile and in the sniffer's device-selection toolbar.

5. Recommended order of attack

Ghidra is installed and current at 12.1.3 under C:\Users\david\ghidra\, running on Temurin JDK 21.0.7, but it was not needed. LiteJam's public web clients provide a clearer and more authoritative description of the working interface than lower-level executable inspection.

6. What an Android device actually buys

Since the APK is obtainable without one, the case for hardware rests entirely on capture iteration.

Android provides Bluetooth HCI logging as a standard Developer Options toggle. The resulting btsnoop_hci.log opens natively in Wireshark and records the user's own phone-to-guitar session in the form available to Android's Bluetooth stack. The practical difference from iOS is the cost per iteration.

This matters because the comparison method is inherently repetitive: record an action twice unchanged, then once with a single parameter varied, and compare. Reducing the cycle from ten minutes to seconds is the difference between a weekend and a month.

One constraint rules out the obvious economy: an emulator cannot substitute. Android Studio's emulator has no Bluetooth radio and cannot connect to physical BLE peripherals. This requires real hardware or nothing.

6.1 Extracting the log

1. Enable Developer Options by tapping Build Number seven times, then enable Bluetooth HCI snoop log. Toggle Bluetooth off and on so it takes effect.
2. Run the session to be captured.
3. Run adb bugreport out.zip and extract FS/data/misc/bluetooth/logs/btsnoop_hci.log.
4. Open in Wireshark. The display filters and opcode tables in the capture guide apply unchanged.

The bugreport indirection exists because /data/misc/ is not world-readable. This is the standard extraction path on an unrooted device; no unlocking or rooting is required.

7. Device selection

The recommendation is to buy a used Pixel for the LiteJam work and to buy a tablet separately if a tablet is wanted for its own sake. Combining the two purchases means spending roughly $300 more for screen size and stylus pressure sensitivity, neither of which contributes anything to reading BLE packets. A $120 phone performs this task identically to a $450 tablet.

The preference for Pixel is not brand loyalty. Manufacturer skins vary in where they place the snoop log and how completely they populate bugreports; Samsung's One UI works but is less predictably documented. When the entire purpose of the device is a debugging workflow, the correct choice is the device the debugging documentation was written against.

The app's stated floor of Android 7.0 is not the binding constraint. Android 9 changed the HCI log's location and Android 12 reworked Bluetooth permissions, so a device older than Android 11 means fighting the toolchain rather than the protocol. The savings from buying a 2017 handset are not worth the added friction.

Avoid: Amazon Fire tablets, which run Fire OS without the Play Store and make a poor development target; anything on Android Go; and unbranded budget tablets shipping Android 11 or older, which may simply refuse to install the app.

8. Practical cautions

Mirror binaries are unverified. APKCombo is a third-party redistributor. The sound verification is comparing the APK's signing certificate against the Play-distributed copy — which requires a device with the app installed from Play. The circularity is mild but real, and constitutes a secondary argument for the inexpensive Pixel.

Expect a split APK. Public mirrors frequently serve XAPK bundles rather than a single monolithic APK. Standard Android inspection tools read base.apk; split configuration files mainly contain resources and native libraries.

Native libraries may hold the protocol. If base.apk reveals that the BLE framing is implemented in a bundled .so rather than in Java, the analysis moves back to Ghidra — but against an unencrypted ARM library, which is a far more tractable target than an encrypted iOS binary.

Conclusion

The decisive fact is that multiple publicly distributed implementations describe the same interface, and LiteJam's browser code is directly readable. Standard Android tooling can also display names and constants from a public APK, but the web client is the clearer source and makes lower-level work unnecessary.

Because the APK is obtainable on Windows, no hardware purchase gates the work. Static analysis can begin immediately, and it should, because it answers questions — the full command set, the exact checksum, any handshake constant — that no volume of packet capture will ever answer.

The remaining case for an Android device is real but narrower than it first appeared: it converts capture from a ten-minute batch cycle into a near-instant loop, which materially changes how much differential analysis is practical. That is worth roughly $120 for a used Pixel. It is not worth $450 for a tablet, and it is not a prerequisite for starting.