Inside the Viwoods AiPaper Reader: A Complete Hardware Audit via ADB
Context: What Is This Device?
The Viwoods AiPaper Reader (model SE08) is a phone-shaped Android 16 e-reader released in November 2025, priced at $279. It has a 6.13-inch E Ink Carta 1300 display at 300 PPI, a MediaTek Helio G99 SoC, 4 GB RAM, 128 GB storage, 4G LTE with a SIM slot, and a dedicated AI button. It weighs 138 grams and is 6.7mm thin.
Public reviews praise the display quality and portability but note the lack of warm frontlight, no speaker, and only 4 GB RAM. What none of them cover is what's actually happening at the hardware level. That's what this audit is about.
Everything below was gathered through ADB over WiFi, using su 0 for root access, reading kernel interfaces, dumping services, and enumerating I2C buses. If your ADB access is locked after firmware v1.3.4+, see Bypassing ADB Restrictions on the Viwoods AiPaper Reader first.
Getting Root Without Magisk
The AiPaper Reader ships as a userdebug build. This is unusual for a consumer device and means su is available out of the box, no bootloader unlock or Magisk required.
$ adb shell su 0 id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),
1011(adb),1015(sdcard_rw)... context=u:r:su:s0
su binary on this device uses su 0 <command> rather than the standard su -c <command>. The latter returns "invalid uid/gid" errors.
Despite root being available, the device reports verified boot state green and a locked bootloader. SELinux is enforcing. The build is signed with release keys. This suggests Viwoods intentionally ships with root accessible, likely for their own debugging and update tooling, rather than it being an oversight.
| Property | Value |
|---|---|
ro.build.type | userdebug |
ro.boot.verifiedbootstate | green |
ro.secure | 1 |
ro.boot.flash.locked | locked |
| SELinux | Enforcing |
The E-Ink Display Pipeline
This is where things get interesting. The official spec says "824x1648, 300 PPI" and leaves it at that. The kernel tells a different story.
Native Panel Resolution
Reading /proc/mtkfb reveals the actual LCM (LCD Module) driver registration:
LCM Driver=[wisky-eink-vdo] Resolution=548x844, Connected:N
FPS = 72, display mode idx = 0, vdo mode 0
The native e-ink panel is 548 x 844 pixels. The Android framebuffer presents 824 x 1648 to applications, which is exactly a 1.5x upscale in both dimensions. The MediaTek display pipeline handles this transparently, and applications see the higher resolution. The "300 PPI" marketing figure is calculated from the upscaled resolution against the physical screen size.
The Display IC Chain
E-ink displays can't be driven like LCDs. They need specialized power management (high-voltage waveforms for the electrophoretic particles) and a bridge to convert standard video signals into EPD timing. Enumerating the I2C bus reveals the complete chain:
| IC | I2C Address | Role |
|---|---|---|
| SY7636A (Silergy) | Bus 4, 0x62 | E-Ink PMIC, generates the high voltages needed to drive the EPD |
| TC358867 (Toshiba) | Bus 6, 0x68 | HDMI/MIPI-to-EPD bridge, converts video frames into EPD waveforms |
| gate-ic-i2c | Bus 7, 0x11 | EPD gate driver, controls row scanning of the e-ink panel |
The kernel logs confirm these components are active, with EinkConsumer and EinkProducer threads handling the display pipeline:
EinkConsumer: wisky SN sn_str = 0 br_ptr = 0
EinkProducer: wisky SN sn_str = 0 br_ptr = 0
EinkConsumer: --chencx power_good=0--
The "wisky" prefix appears everywhere, both in the LCM driver name and the kernel logs. Wisky is a Chinese ODM (Original Design Manufacturer) that specializes in e-ink devices, confirming that Viwoods contracts the hardware design to Wisky and layers their software on top.
Panel Driver Details
The panel operates in VDO (video) mode with sync events, using a high-speed rendering path. SurfaceFlinger reports the display as running at 85 Hz VSync with a configurable range up to 121 Hz. This is the framebuffer refresh rate, not the e-ink panel's actual update speed, which is governed by the EPD waveform timing in the TC358867.
Frontlight
The frontlight is controlled via the standard Linux LED class at /sys/class/leds/lcd-backlight/. Range is 1-255 with the current brightness at 11 (about 4.3%). There is no warm-light LED, confirming the cool-only frontlight that reviewers note as a limitation.
I2C Bus Map: Every Chip on the Board
Enumerating all I2C devices with ls /sys/bus/i2c/devices/ and reading their name sysfs attributes reveals 10 I2C buses with 20 addressable devices:
| Bus | Address | Name | Function |
|---|---|---|---|
| 0 | 0x38 | fts | FocalTech touch controller (primary) |
| 0 | 0x5D | gt9886 | Goodix touch/digitizer (secondary, inactive) |
| 2 | 0x0C | camera_main_three_a | Camera sensor 3 |
| 2 | 0x0D | camera_main_two_af | Camera 2 autofocus motor |
| 2 | 0x10 | camera_main_two | Camera sensor 2 |
| 2 | 0x51 | camera_eeprom | Camera calibration EEPROM |
| 4 | 0x1A | camera_sub | Front camera sensor |
| 4 | 0x51 | camera_eeprom | Camera calibration EEPROM |
| 4 | 0x62 | sy7636a | E-Ink PMIC |
| 5 | 0x34 | mt6375 | Sub-PMIC (charger, USB-C) |
| 6 | 0x68 | tc358867 | HDMI-to-EPD bridge |
| 7 | 0x11 | gate-ic-i2c | EPD gate driver |
| 8 | 0x1A | camera_main | Main camera sensor |
| 8 | 0x50 | camera_eeprom | Camera calibration EEPROM |
| 8 | 0x72 | camera_main_af | Main camera autofocus motor |
Bus 5 has several dummy entries at addresses 0x1A, 0x3F, 0x4A, 0x4E, and 0x64, which are MT6375 sub-addresses used by the MediaTek PMIC driver for different register banks.
Ghost Cameras: Wired but Dark
One of the most surprising findings. The I2C bus shows four camera sensors with autofocus motors and calibration EEPROMs, all physically wired and responding on the bus. Yet:
$ adb shell dumpsys media.camera
Number of camera devices: 0
Number of normal camera devices: 0
Zero cameras registered in the Camera HAL. The hardware feature flags in pm list features even declare full camera support: front camera, rear camera, autofocus, flash, RAW capture, manual sensor control, and "camera.level.full".
This strongly suggests the AiPaper Reader shares a PCB design (or at least a reference design) with a camera-equipped device, likely a Wisky phone reference platform. The camera sensors are physically populated on the board but disabled at the HAL level for the e-reader product. Viwoods (or Wisky) chose not to depopulate the camera components, probably because the BOM savings weren't worth the separate PCB revision.
CPU and GPU Deep Dive
CPU: Helio G99 (MT8781V/CA)
The MT8781 is the tablet variant of the MT6789 (Helio G99). The "V/CA" suffix indicates the specific speed grade.
| Cluster | Cores | Architecture | Freq Range | Steps |
|---|---|---|---|---|
| LITTLE | 6x cpu0-5 | Cortex-A55 (0xd05) | 500-2000 MHz | 24 |
| big | 2x cpu6-7 | Cortex-A76 (0xd0b) | 725-2200 MHz | 16 |
The governor is sugov_ext, MediaTek's extended schedutil governor. At idle, the LITTLE cores drop to 500 MHz while the big cores stay at 2200 MHz (likely due to the ADB session and background services keeping them pinned).
GPU: Mali-G57 MC2
The GPU frequency table from /proc/gpufreqv2/gpu_signed_opp_table shows 45 OPP (Operating Performance Point) steps ranging from 390 MHz to 1100 MHz. Not that it matters much for an e-ink reader, but it supports OpenGL ES 3.2 and Vulkan 1.3 with compute, making it capable of running GPU-accelerated AI inference if anyone wanted to.
$ ls /vendor/lib64/egl/
libGLES_mali.so
libGLES_meow.so # MediaTek's PQ (Picture Quality) wrapper
libMEOW_data.so
libMEOW_qt.so
libMEOW_trace.so
"MEOW" is MediaTek's internal codename for their GPU driver wrapper layer. The libGLES_meow.so library intercepts OpenGL calls to apply MediaTek's display pipeline optimizations, though on an e-ink device these are largely moot.
Touch and Input Devices
Primary: FocalTech FTS
The main touchscreen uses a FocalTech FTS controller at I2C address 0x38 on bus 0. It supports 10-point multitouch (jazzhand), pressure sensing (0-1.0 normalized), and touch major/minor axis reporting up to 1842.52 units. The sysfs path is /sys/devices/platform/soc/11e00000.i2c/i2c-0/0-0038.
Mystery: Goodix GT9886
A Goodix GT9886 sits on the same I2C bus at address 0x5D. The GT9886 is a high-end touch controller often used for active pen/stylus digitizer layers. It's present on the I2C bus but generates no input events in Android's input system. The device's pm list features does not declare stylus support.
Given that Viwoods sells the larger AiPaper tablets with pen input, and the GT9886 supports EMR pen digitizing, this may be a shared PCB component that's only firmware-activated on pen-compatible models.
The AI Button
The dedicated AI button appears as a virtual input device named AI KEY at /sys/devices/virtual/input/input5. It sends standard Android key events and is not natively remappable without root or a Magisk module. The XDA community has published remapping guides.
Other Input Devices
| Device | Purpose |
|---|---|
mtk-kpd | Hardware keypad (volume buttons) |
mtk-pmic-keys | PMIC power button |
ln4913 | Hall sensor / magnetic cover detection |
mt6789-mt6366 Headset Jack | 3.5mm jack insertion detection |
gf-keys | Goodix fingerprint navigation keys |
uinput_nav | Virtual navigation input |
0xd4). Reviews universally state "no 3.5mm audio jack," but the hardware detection circuitry is present. Whether there's a physical jack or it's only used for USB-C audio adapters would require physical inspection.
Connectivity Stack
WiFi
The WiFi chipset is integrated into the MT8781 SoC (MediaTek's combo connectivity). It supports Wi-Fi 5 (802.11ac) on both 2.4 GHz and 5 GHz with an 80 MHz channel width, achieving 433 Mbps link speed in testing. The driver supports WPA3-SAE, OWE, Wi-Fi Direct, Passpoint, DPP, WAPI, and randomized MAC addresses for scanning, station, AP, and P2P modes.
Cellular
The device has a full telephony stack with baseband firmware MOLY.LR13.R2.MP.V217. Despite being marketed as "data only," the modem supports voice calls and SMS, as multiple reviewers discovered. Viwoods officially states support for LTE bands B1/B2/B3/B5/B7/B8/B20/B28/B38/B40/B41, covering most European and US GSM carriers. T-Mobile USA is confirmed working.
Without a SIM inserted, the radio still searches for networks and registers for emergency services (E911), which is standard Android behavior.
Bluetooth
Bluetooth 5.x with a full profile stack (A2DP, AVRCP, HFP, HID, MAP, OPP, PAN, PBAP, SAP, BLE GATT, BAS). It was powered off and had never been enabled since the last boot.
GNSS
Full GNSS support with GPS (L1), Galileo (E1), GLONASS (G1), BeiDou (B1I), and SBAS. Capabilities include raw measurements, navigation messages, low-power mode, satellite PVT, and measurement corrections. This is standard for the Helio G99 platform.
NFC
The NFC service APEX module is installed (com.android.nfcservices), but there is no NFC hardware. No /dev/nfc device nodes, no NFC in pm list features, and the dumpsys service doesn't exist. This is just the standard Android 16 system image including NFC support that has no hardware to bind to.
Declared but Absent Hardware
Android's pm list features declares hardware capabilities that don't match what the kernel and sensor service actually expose. This is a common issue with MediaTek reference platforms where the feature list comes from the BSP (Board Support Package) rather than the actual hardware population.
| Feature Declared | Reality |
|---|---|
android.hardware.sensor.barometer | Not in sensorservice |
android.hardware.sensor.compass | Not in sensorservice |
android.hardware.sensor.gyroscope | Not in sensorservice |
android.hardware.sensor.light | Not in sensorservice |
android.hardware.sensor.proximity | Not in sensorservice |
android.hardware.camera (full) | 0 cameras in HAL |
android.hardware.sensor.hifi_sensors | Only basic accelerometer present |
android.hardware.sensor.accelerometer | Present: Rohm KXTJ3 |
android.hardware.fingerprint | Present: Goodix |
android.hardware.touchscreen | Present: FocalTech FTS |
The only real sensor is the Rohm KXTJ3 accelerometer. Everything else (orientation, gravity, linear acceleration, rotation vectors, step counter, tilt, wake gesture) is computed by MediaTek's virtual sensor fusion layer from that single accelerometer. Without a gyroscope or magnetometer, these virtual sensors are approximate at best.
Widevine DRM
The Widevine DRM plugin is present in the system image but fails initialization. The media.metrics dumpsys shows mediadrm.errored events during initCheck and createPlugin. Only ClearKey DRM is functional. This means the device cannot play L1-protected content from Netflix, Disney+, or similar streaming services at HD quality.
ADB Findings vs. Public Specs
Here's a summary of things discovered through ADB that aren't mentioned in any official spec sheet, review, or teardown:
| Finding | Detail | Significance |
|---|---|---|
| Native panel resolution | 548x844, upscaled to 824x1648 | The "300 PPI" is calculated from the upscaled resolution |
| E-Ink PMIC | SY7636A (Silergy) | Powers the electrophoretic display |
| EPD bridge IC | Toshiba TC358867 | Converts video to EPD waveforms |
| ODM identity | Wisky (in driver names and kernel logs) | Viwoods doesn't make the hardware |
| 4 camera sensors | Wired on I2C but disabled in HAL | Shared PCB with a phone/tablet reference design |
| Goodix GT9886 | Pen digitizer IC present but inactive | May share PCB with pen-enabled AiPaper models |
| Root via su | Userdebug build, no Magisk needed | Intentional, despite locked bootloader and verified boot |
| Headset jack detection | Kernel switch device with full headset/mic detection | Hardware present despite "no 3.5mm jack" in reviews |
| Voice wakeup DSP | RISC-V VOW (Voice on Wakeup) processor | Always-on voice detection hardware, unused by Viwoods software |
| FM Radio hardware | App and hardware driver present | Never mentioned in any review or spec sheet |
| Sensor mismatches | 5 sensors declared but absent | BSP feature list not trimmed for actual hardware |
| Widevine failure | DRM plugin present but not provisioned | No HD streaming from protected services |
The AiPaper Reader is, at its core, a MediaTek Helio G99 phone reference design by Wisky, with the cameras disabled in software, the display pipeline rerouted through a Toshiba EPD bridge to a 548x844 e-ink panel, and Viwoods' Android 16 software stack layered on top. The hardware is significantly more capable than what's exposed to the user, with dormant camera sensors, a pen digitizer IC, voice wakeup DSP, and FM radio all sitting idle on the PCB.
