You could view my original note
here if you want, as vBulletin used by MobileRead might break certain formatting, and the former would update first before this post.
I've been poking around the software on my Likebook Mimas (but the info here should also apply to any other Boyue device running on the Rockchip RK3368 platform), primarily in order to find a way to root it, but also because I don't like how Boyue seemed to have removed certain features from their Android 6 release, like background support, the entire lock screen (including Google Smart Lock, and in favour of Boyue's lazy-ish passcode lock), as well as screen recording and wireless display support.
I can't go further without a full system image to recover from, but wanted to share my findings here on MobileRead, in the event that it could help others get further. If you don't have one of these devices, I could help to provide screenshots and/or shell transcripts from my Mimas, unless it's not with me as I have to send it back to Boyue to get the pen digitizer replaced.
(The original note was about "hacking" the software, but I later felt that wasn't the right word, so the rest of this post may sound strange)
Missing resources:
- Factory and/or OTA images for these devices (note to self: try to find time to do packet capture on both Boyue updater and handwriting recognition to see which Web locations are being pinged)
- Proper Android development target and/or other source code repositories
From what I know, the Likebook firmware, at least for their Android 6 based release, appears to me to be basically a hodgepodge of a few different Android releases. Here are some examples:
- Boyue's Android 6 release seems to be missing some components, like:
- Lock screen (and subsequently, Google Smart Lock)
- Screen capture for video
- Background support for home and lock screens
- "Android security patch level" in settings
- Regional options for languages
- (I used one of those "language changer" apps to get around this)
- USB debugging status icon appears to be from Android 4.1-4.3
- Included web browser appears to be from Android 4.0, and has forced A2 mode,
- so I use Firefox instead (though actually a modified version called "Fennec F-Droid" that just removes some Mozilla annoyances).
- The sound recorder, at least judging by its icon used outside the Likebook home shell, seems to be from Android 4.x
- Gallery seems to be from Android 4.x, or at least uses a custom UI based on the "Holo" UI.
- Music player seems to be from Android 2.x. it feels clunky on the large screen,
- so I use "Phonograph" and Simple Mobile Tools "Music Player" instead.
Here's what I found:
- Running an "env" shows that the software seems to be set up to accept Adobe Digital Editions DRM in the built-in reader, however, it might not be.
- However, I'd rather stick to tablet apps provided by e-book services I buy my e-books from (unless it's self-published books purchased direct from the author) so that my annotations, if the book is formatted in a way that I can do so, will sync across devices.
- It may be possible to get into recovery on devices with a single face button by holding down that and the power button, but I don't own any of those, so I can't check. However, what I do know is that "adb reboot recovery" should work.
- If you have a Mimas, you can also:
- Power on while holding [Page Left] to get into Android recovery.
- Plug in a USB cable connected to your PC while holding down [Page Left] to get into "LOADER" mode.
- Hold down [Power] until the indicator on the bottom turns off to power off. Doing the same after that should land you back in the Android system after a minute or so.
- The usual controls of using the volume keys (page keys on the Mimas) and pressing [Power] to select are still present, but then there additional controls displayed on the screen, which most likely are for users on the Muses, Alita, and Ares Note, as those have a singular face button, but may also work for those on the Mars.
- Those read, "Any button cycles highlight. Long-press activates."
- Telling ADB (Android Debug Bridge) to restart to the bootloader ("adb reboot bootloader") appears to instead restart into the Rockchip "LOADER" mode.
- This is indicated by the display not updating and leaving the image of whatever was shown on the Android system prior to restarting, the charge and startup status indicator on the bottom being frozen, and the Android Fastboot tool on the PC side hanging on "waiting for any device" until I pressed [Control]+[C] to get out of it.
- Some time later, I retried it, but this time with the actual Rockchip USB drivers and "AndroidTool", to confirm that my Mimas had in fact been rebooted into "LOADER" mode.
- The tool loaded for me in Chinese, but changing "Selected=1" to "Selected=2" in the "config.ini" does the trick
- My PC dual boots Windows and Debian, however, I was on the Windows side at the time for a completely unrelated reason.
- The "AndroidTool" seems to include a feature to restart into "LOADER" or "MASKROM" modes from a running state, which does still require Android USB debugging. I was only able to get into the former using this, but I fear I may not be able to get out of the latter once I restart into that, despite there being a "Go Maskrom" (sic) button on the "Advanced" tab.
- I can do "Read Flash ID", "Read Flash Info", and "Read Chip info, but "Read Capabilities" fails.
- The tool does not stop the ADB server after selecting "Switch", so you'll need to kill the ADB process before you delete the tool, should you want to.
- Unfortunately, this does mean I can't run TWRP in RAM to test it.
- I can't proceed with actually flashing a custom recovery, as there seems to be NO Android system images for any of the currently supported Likebook models.
- I suspect that all the RK3368 based Boyue/Likebook devices use the ITE IT8951 for its display controller, as I noticed that there's no usual ZIP file for the splash screen in /system/media, only the "powered off" and "out of power" images, and the default screensaver.
- However, this makes me wonder where the "charging before starting up" and startup screens are located.
- I suspect it's in the EEPROM or flash storage of the display controller itself, as the IT8951 supposedly has a "boot up auto display" feature, but I can't confirm this as I haven't found any documentation on how to set that (or any of its more advanced features) up.
- The IT8951E-64 is the chip used on the E-ink ICE development board, and Waveshare's more accessible (to individuals) clone that added Raspberry Pi support. Thus, it's likely that Boyue uses this same chip.
- I do believe the screensaver is converted to a greyscale bitmap and written to the display controller's flash or SRAM. so that it can automatically display when it gets sent the "sleep" command, after Android turns off what it thinks is a LCD, which should explain why it can't cycle through multiple like on Kindle and Nook devices.
- Even then, if it does have one, I don't know which bus it's connected over, as the chip can talk over 1 of 4 different bus options, but I suspect it's being interfaced to over either i2C or SPi. I guess one could look for zero ohm links near it after getting the device apart and looking at the internals.
- Android DPI settings: (both displays run at 1404×1872)
- Mimas/Alita (10.3 inch, 226ppi): 240 dpi (slider ranges from 200 to 480)
- Mars/Muses/Ares Note (7.8 inch, 300ppi): ???
Shell snippet 1 - Environment variables:
Spoiler:
Code:
shell@T103D:/ $ env
_=/system/bin/env
ANDROID_DATA=/data
RK_ADEPT_ACTIVATION_FILE=/mnt/sdcard/.adobe-digital-editions/activation.xml
RK_ADOBE_DE_DOC_FOLDER=/mnt/sdcard/Digital Editions
HOME=/data
RK_ADEPT_DEVICE_TYPE=mobile
RK_ADEPT_DEVICE_SALT_FILE=/mnt/sdcard/.adobe-digital-editions/devicesalt
EBOOK_PAGE_VISIBLE_NUMBER=2ÒÇÇ
USER=shell
ANDROID_ASSETS=/system/app
BOOTCLASSPATH=/system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/telephony-common.jar:/system/framework/voip-common.jar:/system/framework/ims-common.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/apache-xml.jar:/system/framework/org.apache.http.legacy.boot.jar
ANDROID_SOCKET_adbd=12
RK_ADOBE_DE_MOBILE=1
ANDROID_STORAGE=/storage
MKSH=/system/bin/sh
SYSTEMSERVERCLASSPATH=/system/framework/services.jar:/system/framework/ethernet-service.jar:/system/framework/wifi-service.jar
TERM=xterm
SHELL=/system/bin/sh
ANDROID_BOOTLOGO=1
ADOBE_FONTS_DIR=/system/fonts/adobefonts/
RK_ADEPT_DEVICE_FILE=/mnt/sdcard/.adobe-digital-editions/device.xml
ASEC_MOUNTPOINT=/mnt/asec
HOSTNAME=T103D
TMPDIR=/data/local/tmp
PATH=/sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
ANDROID_PROPERTY_WORKSPACE=10,0
ANDROID_ROOT=/system
EXTERNAL_STORAGE=/sdcard
shell@T103D:/ $
Shell snippet 2 - Root folder listing:
Code:
shell@T103D:/ $ ls /
acct
cache
charger
config
d
data
default.prop
dev
drmboot.ko
ebc_waveform.bin
etc
file_contexts
fstab.rk30board
fstab.rk30board.bootmode.emmc
fstab.rk30board.bootmode.unknown
init
init.connectivity.rc
init.environ.rc
init.rc
init.rk30board.bootmode.emmc.rc
init.rk30board.bootmode.unknown.rc
init.rk30board.environment.rc
init.rk30board.rc
init.rk30board.usb.rc
init.rockchip.rc
init.tablet.rc
init.trace.rc
init.usb.configfs.rc
init.usb.rc
init.zygote32.rc
init.zygote64_32.rc
metadata
mnt
oem
proc
property_contexts
res
rk30xxnand_ko.ko
root
sbin
sdcard
seapp_contexts
selinux_version
sepolicy
service_contexts
storage
sys
system
ueventd.rc
ueventd.rk30board.rc
vendor
wacomT103dFw.hex
shell@T103D:/ $
Shell snippet 3 - /dev listing:
Let me know if you want me to open any file or folder and show you the contents, in either the ADB shell or the free non-root version of Root Explorer. I also have Termux and Termius, and can run commands in the locked-down local terminal, as well as through the ADB shell.
Shell snippet 4 - Android build properties:
Shell snippet 5 - Rockchip AndroidTool v2.69 stuff:
What I plan to do next is to try and see if I can try and trace to get some kind of OTA image, by doing packet capture. However, most likely, OTA update images won't be as complete as the full factory images would be.