Open-Source Fixes and Apps for the Lenovo Googlebook 15

Sleep Guard gives the hardware a moment to finish before the laptop goes back to sleep. It notices every wake that happens with the lid closed within about 5 milliseconds and checks again 15 milliseconds later that the lid really is closed. Then it briefly tells GooglebookOS that the lid is open for power purposes, which makes wakelocks work again, while it keeps the screen and the glow bar off. The hold lasts 0.3 seconds, and it stretches to a 20-second settle period when the charger has changed. After that, everything is released and normal deep sleep resumes.

It was proven live on October 10, 2026. An unplug during deep sleep was caught 87 milliseconds after the wake, a plug-in was caught 18 milliseconds after the wake, and the laptop stayed up overnight.

Safety was treated as seriously as the fix. An early version once stalled the power service for about two minutes, so the helper now reads system service output asynchronously with a deadline and a size cap. Every command has a time limit, and a watchdog releases everything and exits if the helper ever stalls. After every exit, it restores the real lid state. On a new GooglebookOS build, it runs a self-test and stands down with a notification if anything has changed, instead of guessing. It also notices when Wireless debugging moves to a new port after a Wi-Fi drop and publishes the new port, so the app can always reconnect.

Sleep Guard wins a timing race. It is not a firmware fix. Opening the lid before unplugging the charger is always completely safe.

While Shadow holds pointer capture, the helper takes exclusive control of the trackpad, reads the raw finger data itself and runs its own gesture engine. It sends cursor moves and clicks straight to Shadow. Scrolling is sent as a synthetic two-finger touchpad drag, which Shadow's own gesture code turns into fine-grained Windows scrolling. Pinch is sent as Ctrl plus that drag, which is how Windows precision touchpads zoom. GooglebookOS intercepts the Windows key and Alt+Tab, so three-finger swipes use the Ctrl+Alt+Tab switcher instead, and four-finger swipes send Back and Forward. The moment capture ends, the trackpad goes back to Android.

It is fast. In an A/B test, the time from finger to app was 9.4 milliseconds with the helper and 11.2 milliseconds with Android's own handling, with no lost movement.

It was built to be safe and to keep working. A watchdog releases the trackpad if the helper stalls for 1.5 seconds. The app proves it is talking to the real adb service before it hands over any secret, and that secret is derived from the paired key, so only the Linux Terminal and the app can compute it. After an update, the doctor decompiles the new Shadow app, re-checks every assumption the helper relies on, and switches any broken feature to a safe fallback until the check passes again. Before release, the code went through three rounds of independent review by AI code reviewers, and a fuzz test ran one million gesture sequences with zero stuck keys or buttons. The final doctor run passed all 25 checks.

The real fix belongs in Shadow itself, which could keep the fractional scroll steps or request absolute capture mode.

The crash was fixed by reinstalling the same Play Store copy of the plugin in its ARM version, which contains all of its libraries. GooglebookOS translates it to run on the Intel processor. The plugin kept its data and its Play Store link, and it received the Nearby devices permission it had never been given. The widget then appeared by itself.

To solve the connection problem, the plugin's code was studied to find out what makes it connect. At startup, it sends itself an internal "ready" signal, and its handler for that signal does count LE Audio as connected. Any app is allowed to send that signal. Buds LE Link sends it twice, a few seconds after the earbuds connect. The first signal refreshes the plugin's stale state, and the second one opens the control channel. Audio stays on LE Audio the whole time. In the first test, the link came back about 4 seconds after the earbuds came out of the case.

I wanted it to be foolproof, so version 2 added the 15-minute check, the status window, and self-checks for every permission and battery setting it needs, with a Fix button for each one in the status window. Version 2.2 turned that window into a normal one that closes cleanly. Version 2.3 came after a GooglebookOS update switched the plugin back to its Intel version during the restart. Now, after every restart, Buds LE Link checks the plugin, and if it is in Intel mode, the app reinstalls it in ARM mode by itself through its own Wireless debugging pairing. In my test it was back in ARM mode 1.1 seconds later. Version 2.4 came after the plugin got stuck after days of running and stopped trying to connect. Now, when the earbuds play audio but the plugin has had no control link for five minutes, Buds LE Link restarts the plugin by itself, at most once every 30 minutes. In my test it was connected again 3 seconds later. Both fixes depend on how this exact version of Samsung's plugin behaves, so a Samsung update could undo them, and the app warns me if a different plugin version is installed.

The 2021 version of Gmail Go has no web mode, keeps its own push receiver and mail sync, and targets an Android version old enough that its notification permission can be granted from adb. Google's own signed copy of it was installed, granted that permission, exempted from battery limits and set to stay silent. When new mail arrives, Google's push wakes Gmail Go even if it has been closed, and it syncs the email. Notification Keeper then posts its own pop-up copy and removes Gmail Go's original. The whole chain takes about 1 to 1.5 seconds from Google's push to the pop-up. If the Gmail web app is open and posts its own alert as well, the Keeper removes that duplicate.

Tap, Reply and Delete open the right account's inbox in the Gmail web app. The helper finds the email by its exact subject and arrival time, and then it opens the email or uses Gmail's own menu to reply or delete. It only touches the screen when Gmail is the active window and nothing covers it. For Reply and Delete, it removes the notification only after the action succeeds. Mark as read works without opening anything. The background service runs on the Googlebook itself and keeps a hidden browser signed in to each Gmail account, finds the unread email by sender address, subject and time, and clicks Gmail's own Mark as read button. Each one takes about 4 to 6 seconds. It started out in the Linux Terminal, but the Terminal stops whenever its window closes, so it now runs on GooglebookOS with the same browser and sign-ins, and a small app starts it again after every restart. A settings guard saves my Gmail notification settings and puts them back if they are ever reset.

Every part was proven on October 12, 2026, including notifications with Gmail Go closed, Mark as read on more than one account, and tap, Reply and Delete. Mark as read on GooglebookOS itself, with the Linux Terminal closed, was proven on November 3, 2026. Archive was left out because Android shows at most three buttons on a notification. Mark as read needs Wireless debugging on so the app can start it after a restart, and it works for @gmail.com and @googlemail.com accounts only.

The Keeper is a notification listener. It recognizes notifications that Chrome delivers for websites and web apps, and it watches for the moment one is withdrawn by the app itself. It ignores notifications that I swipe away or tap. When an alert is withdrawn, the Keeper posts a copy with the same title, text and icon on its own "Kept web notifications" category, which keeps it in the Notification Center. It keeps up to 15 copies, because Android allows each app only 50 notifications. A Run test button posts a fake web notification and withdraws it after 7 seconds, so anyone can check that the Keeper catches it.

This generic keeping already works for any web app's withdrawn alerts without any changes. The rich features are the action buttons, the settings guard, and a privileged link that lets the Keeper manage another app's notification categories. Those are written only for Gmail and Gmail Go. Bringing them to other web apps means editing the app names written into the code and writing matching logic for each app, and that is the work this project invites other developers to do.

The Keeper cannot make a closed web app notify. For Gmail, that part is handled by Gmail Go, as the card above explains.

I read the Home Depot app's manifest and followed the links behind the buttons in my own Home Depot emails. The app handles its website's account addresses natively, and "Manage Order" ends at the order details address for one order number, while "Check Order Status" ends at the purchase history. The helper builds the same address from the order number in the notification and hands it to the Home Depot app, so orders need no screen tapping at all. The Keeper only passes the subject and preview to the helper, and keeps working exactly as before when the helper is not installed.

A verification code cannot be opened by a link, so the helper has one accessibility service for that. It receives events only from the Home Depot app, looks at the screen only while a code is waiting, prefers a field whose label mentions a code, never types into a search, email or password field, performs no gestures, and gives up quietly after 45 seconds with the code still on the clipboard. Android switches an accessibility service off after every update, so with one permission granted over adb the helper switches its own service back on by itself. I tested a card tap landing on the order page and the code typing on screen, and the typing check had to learn that a web page may reformat the digits it was given.

The Nearby devices permission was granted to Settings Services over adb from the Linux Terminal. The widget refreshes when a Bluetooth device connects, and it only lists devices that are connected at that moment. When I reconnected the earbuds, both the Galaxy Buds4 and the Pixel Buds 2a appeared in the widget right away.

To make the fix stick, the permission was marked as my own choice, so the system treats it as a deliberate setting. Android's automatic removal of permissions from unused apps was also turned off for Settings Services. The fix-battery-widget command repeats all of these steps and prints the result, so I can see that it worked.

Waydroid's network script was switched to nftables, which the kernel fully supports, and Android then booted in about 18 seconds with working internet and Google Play. A systemd drop-in re-applies that change every time Waydroid starts, so package upgrades cannot undo it. The unused LXC network service, which failed in the same way, was turned off.

Auto-freeze was switched off, so Android keeps running in the background. A 4 GB swap file was added at a lower priority than the fast compressed swap, which freed enough memory for the Play Store to run smoothly. I registered the device with Google so I could sign in to Google Play, and the two launcher buttons were added and tested.

An app that ships only with 64-bit ARM libraries installed successfully from Waydroid's Play Store, but no ARM app has been launched and tested yet. The virtual machine has no GPU acceleration, so Android draws everything in software. Waydroid's window appears only inside the Linux Terminal's display view, and apps with strict integrity checks usually refuse to run.

Before the app was installed, its download was checked against the checksum published on GitHub and its signature was verified. It was given the local network and notification permissions, allowed to run in the background and exempted from battery saving, so the connection does not drop when the app is not in front. Each device was paired once over Wireless debugging and added by the IP address and port shown on its Wireless debugging screen. The stream was limited to 1920 pixels at 60 frames per second, which removed the lag and made the stream much smoother.

The app mirrors one device at a time in a single window, and it streams the device instead of handing apps over the way Continue On does. After a device restarts, its Wireless debugging port changes, so the saved entry needs the new port. Apps that block screen capture show a black screen.

A native Kotlin app on the Android side is the IDE: an editor with language servers, AI completions, Ctrl K and an inline review of every change, the terminal and the chat, with no browser and no WebView. A pure Python server in the VM runs the agent with a tool protocol an 8B model follows reliably, checkpoints for every change, automatic syntax checks after every edit, and a prompt cache strategy that makes follow-ups answer in seconds. Memory guards show the VM's free RAM, refuse to load the model into a full VM and unload it before the VM gets into danger. Helpers such as the language servers, the debugger, notebook kernels and the small embedding model start only when needed and only when a memory check passes, and they stop again when they are not used.

For the GPU, I cross-compiled llama.cpp's Vulkan backend for Android and packaged it into the Forge app, where the Intel graphics are reachable. The app downloads the weights once from Ollama's store, asks the VM to hand memory back, and serves the model to the IDE. Prompt processing went from 10 to 23 tokens per second to about 100, the first token of a cold agent prompt from 134 seconds to 9, and a three-step agent task from 257 seconds to 50, with no model memory left inside the VM.