Dorian's avatar
Dorian 3 weeks ago
Appreciate the swift response. Makes total sense. In theory, would it be possible to run an OS on the Daylight that didn’t need to talk to Google and the App store at all? I know it’s baked into their current system. I’m good to access certain apps through the pixel - but would like to use the daylight just to read/write. I’ve read some loose discussion around hacking it and curious if anyone has found any progress.

Replies (2)

Viktor's avatar
Viktor 3 weeks ago
possible? sure. easy? nah - daylight ships with the usual google glue (play service stubs, safetynet hooks) baked pretty deep cos that's what their first-run ux expects. but inside it's android 13 with unlockable bootloader, so full AOSP image or even postmarketOS would flash clean. problem is their e-ink panel driver & stylus stack - not upstreamed, lives in a closed vendor partition that only their signed system image loads. if you wipe that you lose the low-latency ink magic that makes the device sexy. you'd basically be left with a laggy e-reader running mainline. a nicer play: keep stock android but neuter the google calls. couple devs already replaced play services with microg and patched the safetynet provider to return "attest_success" stub responses. ink still works, apps think they're blessed. it's a whitelist of ~4 proprietary libs + one xml overlay; do it over a magisk style module and you keep ota updates (signed by daylight, not google). wip yolo, zero warranty, but prototype is out there on their gitea - issue #73 iirc ("attestation-bypass-for-foss"). no public bin yet. if ink is optional for you (you just want read / write on epd) you could also boot a halium-based gnu/linux chroot in android userspace, run xournalpp or vim-hd with direct framebuffer ioctl - again, driver blob has to stay resident so full wipe is off the table. tl;dr - keep the vendor blobs, gut the google blobs, or port blobs to new OS. second route is closest to plug-and-play today.
I also have both Pixel and Daylight. The problem is not with the OS communicating with Google. The problem is that the server of the app (X, your bank, or many services that use this tech) won't communicate with the app unless the CPU attests that it is unmodified app running on Google certified unmodified operating system. For details how this works, check the article, it's a bit more complicated, but unless Daylight and graphene pay for Android license and certification and ship Google spyware, the apps won't run - by the sheer fact that the server will refuse to communicate. It's cryptographically secure unfortunately.