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
Note on su syntax The 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.

PropertyValue
ro.build.typeuserdebug
ro.boot.verifiedbootstategreen
ro.secure1
ro.boot.flash.lockedlocked
SELinuxEnforcing

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:

ICI2C AddressRole
SY7636A (Silergy)Bus 4, 0x62E-Ink PMIC, generates the high voltages needed to drive the EPD
TC358867 (Toshiba)Bus 6, 0x68HDMI/MIPI-to-EPD bridge, converts video frames into EPD waveforms
gate-ic-i2cBus 7, 0x11EPD 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:

BusAddressNameFunction
00x38ftsFocalTech touch controller (primary)
00x5Dgt9886Goodix touch/digitizer (secondary, inactive)
20x0Ccamera_main_three_aCamera sensor 3
20x0Dcamera_main_two_afCamera 2 autofocus motor
20x10camera_main_twoCamera sensor 2
20x51camera_eepromCamera calibration EEPROM
40x1Acamera_subFront camera sensor
40x51camera_eepromCamera calibration EEPROM
40x62sy7636aE-Ink PMIC
50x34mt6375Sub-PMIC (charger, USB-C)
60x68tc358867HDMI-to-EPD bridge
70x11gate-ic-i2cEPD gate driver
80x1Acamera_mainMain camera sensor
80x50camera_eepromCamera calibration EEPROM
80x72camera_main_afMain 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.

Could they be re-enabled? Theoretically, if someone provided the correct Camera HAL configuration and sensor drivers, these cameras could be activated. The I2C devices respond, the EEPROMs are present, and the AF motors are wired. The missing piece is the Camera Provider HAL registration in the vendor partition.

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.

ClusterCoresArchitectureFreq RangeSteps
LITTLE6x cpu0-5Cortex-A55 (0xd05)500-2000 MHz24
big2x cpu6-7Cortex-A76 (0xd0b)725-2200 MHz16

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

DevicePurpose
mtk-kpdHardware keypad (volume buttons)
mtk-pmic-keysPMIC power button
ln4913Hall sensor / magnetic cover detection
mt6789-mt6366 Headset Jack3.5mm jack insertion detection
gf-keysGoodix fingerprint navigation keys
uinput_navVirtual navigation input
Headset jack detection exists The kernel registers a headset jack switch device with full detection capabilities (headset, headphone, mic detection via switch bitmask 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 DeclaredReality
android.hardware.sensor.barometerNot in sensorservice
android.hardware.sensor.compassNot in sensorservice
android.hardware.sensor.gyroscopeNot in sensorservice
android.hardware.sensor.lightNot in sensorservice
android.hardware.sensor.proximityNot in sensorservice
android.hardware.camera (full)0 cameras in HAL
android.hardware.sensor.hifi_sensorsOnly basic accelerometer present
android.hardware.sensor.accelerometerPresent: Rohm KXTJ3
android.hardware.fingerprintPresent: Goodix
android.hardware.touchscreenPresent: 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:

FindingDetailSignificance
Native panel resolution548x844, upscaled to 824x1648The "300 PPI" is calculated from the upscaled resolution
E-Ink PMICSY7636A (Silergy)Powers the electrophoretic display
EPD bridge ICToshiba TC358867Converts video to EPD waveforms
ODM identityWisky (in driver names and kernel logs)Viwoods doesn't make the hardware
4 camera sensorsWired on I2C but disabled in HALShared PCB with a phone/tablet reference design
Goodix GT9886Pen digitizer IC present but inactiveMay share PCB with pen-enabled AiPaper models
Root via suUserdebug build, no Magisk neededIntentional, despite locked bootloader and verified boot
Headset jack detectionKernel switch device with full headset/mic detectionHardware present despite "no 3.5mm jack" in reviews
Voice wakeup DSPRISC-V VOW (Voice on Wakeup) processorAlways-on voice detection hardware, unused by Viwoods software
FM Radio hardwareApp and hardware driver presentNever mentioned in any review or spec sheet
Sensor mismatches5 sensors declared but absentBSP feature list not trimmed for actual hardware
Widevine failureDRM plugin present but not provisionedNo 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.