Developer test records

Tests and technical evidence

Documented observations from earlier Android builds, with the devices, methods and limits needed to interpret each result.

Auralis Industries · Page published / updated: October 10, 2026

Whitepaperv2.0.0

Auralis Industries · 2.0.0 · English · 147 pages. This July 2026 edition discusses Android 1.1.7 and iOS 1.1.2 baselines while retaining March tests on earlier builds. Its release-status statements are historical, not a current compatibility or availability list.

Edition date: July 17, 2026

Whitepaper v2.0.0 (PDF, English)

Voice-call continuity through two walls

≈ 212 s

Call duration

Test date: March 15, 2026
Tested build: Android 0.9.9-debug
Devices: Samsung SM-J260F · Android 8.1.0
Samsung SM-G990E · Android 16

Observed result

Both phones recorded approximately 212 seconds before an intentional hangup. Sampled playback logs reported zero loss, underrun and CRC-drop counters.

Method and conditions

A short-range, two-device RFCOMM voice call. Two-wall separation was reported by the tester; both phones used the debug build. The periodic logs showed average jitter-buffer depths of about 199–203 ms.

What this establishes

Evidence of continuity in this single setup. Zero sampled counters are not a universal 0% packet-loss claim. Distance was not measured; this run does not establish a range guarantee, heavy-obstruction performance or end-to-end voice latency.

Read the source section§ 17.5 · A-91

Clock-adjusted packet-age measurement

16–18 ms

Median packet age

Test date: March 15, 2026
Tested build: Android 0.9.9-debug
Devices: Samsung SM-J260F · Android 8.1.0
Samsung SM-G990E · Android 16

Observed result

The two receivers recorded medians of 18 ms and 16 ms, with P95 values of 99 ms and 120 ms, across 3,149 and 3,175 samples respectively.

Method and conditions

An approximately 64–65-second RFCOMM call with monotonic clock-sync probes. Each phone recorded 13 usable synchronization observations. The measured value is clock-adjusted age of received packets.

What this establishes

Packet age is not mouth-to-ear voice latency: audio capture, codec, buffering and playback are not fully represented by this metric. This is one indoor setup on one device pair; the run does not close the broader voice-validation requirements.

Read the source section§ 17.5 · A-92

Standby device-power comparison

+14.1 mW

Additional average device power

Test date: March 15, 2026
Tested build: Android 0.9.9-debug
Devices: Google Pixel 7a · Android 13

Observed result

Over matched windows of about 300 seconds, average device power was 233.6 mW with the app force-stopped and 247.7 mW in app standby: a measured difference of approximately 14.1 mW.

Method and conditions

Pixel 7a, airplane mode on, Wi-Fi off, Bluetooth on, screen asleep and AC power connected. Perfetto power-rail traces compared baseline idle with the app backgrounded and its RFCOMM foreground listener active.

What this establishes

A short, single-device, debug-build comparison. It does not establish unplugged battery life, hours of operation, active-call consumption or isolated SOS BLE-beacon power. Repeated release-build tests on more devices are needed.

Read the source section§ 17.4 · A-90–A-91

Read the result together with its method

The summaries below cite sections 17.4–17.5 of the whitepaper (appendix A-90–A-92). They describe developer observations, not an independent laboratory assessment. A new claim about a current release needs a new dated run tied to the exact build, devices and conditions; logs, repeated trials and a broader device matrix improve reproducibility.

Automated test inventory is a separate record

The March 31, 2026 snapshot lists 38 source files and 197 declared tests. Its recorded unit-test command failed during compilation before tests executed. Those counts describe the historical source inventory, not 197 passing tests or the current suite's status (whitepaper §17.14–17.15).