yashsingh1/xdaforums huggingface dataset:
[Google Home] bj00rn:
Any success on backing up the stock firmware? Maybe this guide will help : https://xdaforums.com/t/backup-full...sing-mtk-client-oppo-reno6-5g-mt6877.4406069/

Im new to this stuff, but from what i gather we need to patch the stock boot.img to get root. Getting the stock firmware would be a good first step.

Mtk client: https://github.com/bkerler/mtkclient
[Google Home] dro1dy:
That sure looks legit and does seem to confirm that there is a way to flash things via the pins on the bottom.

The instructions implying that there's a specific order you need to apply power in could indicate that there's some switching in place on the pogo pcb that only connects the USB data lines when the 5V is applied.
[Google Home] bj00rn:
From the pics it seems that the dock is different though. Stock dock might be a dead end. Im going to give ADB a go using the standard usb connection to see if it works.

I just got these compatible pogo pins https://se.rs-online.com/web/p/pcb-headers/7020461 and they fit perfectly. Shame I don't have the means or skills to make a 3D printed dock. Will have to glue something together for now.
[Google Home] cmccambridge:
Hey all, following the investigation in the thread above, I've successfully dumped the stock firmware that my (used) smart clock 2 arrived with, using mtkclient via soldering on to the USB pins!

USB Connection​

Attaching a closer photo for others to reference:

Note that you do not need to solder to both GND pins there- they're connected together on the PCB. I believe the earlier image was using two ground wires mostly because it was easy to do so? (One for the cable/jack shield, and the other for the black ground wire running through the cable.) In my case I crimped some dupont connectors on, so I simply twisted the cable shield and the black ground wire together into a single pin (look closely at bottom of this image):

I've confirmed the following modes:

MTP: Normally booted up to the "Hi, I'm your Google Assistant" message, the device appears over MTP as shown in previous screen captures. "Lenovo CD-24502F". Appears shortly after the Lenovo boot logo is shown.

Fastboot(?): Booted with Vol + held down, then selecting Fastboot: Device appears on USB as an Android ADB interface, using the Mediatek vendor ID. I have not yet attempted to connect to this interface... just hit it by accident once and saw it pop up. NOte that in this mode, nothing appears to happen on-screen. Just freezes at the menu selection. Not yet sure whether USB Fastboot access is functional there.

Mediatek bootloader (for mtkclient): Briefly connects for a second or so, as others have noted. You must be running the mtkclient at this time to complete the handshake, otherwise this will quickly be removed as the boot process continues. Further, I found the mtkclient and boot process to be a little timing-sensitive. I only get a successful connection about 1 in 5 tries, but DID succeed.

Dumping Firmware​

Haven't tried it over fastboot yet, but via mtkclient this definitely succeeds. Partition table:

Spoiler content hidden.

Rooting​

I have not yet set the device up (never booted past the "hi, i'm your google assistant" prompt), just wanted to capture a full firmware image first as a last resort to return to.

I will take a swing at getting root via Magisk today with the boot.img I extracted. If all goes well, I've got a second smart clock 2 new-in-box to play with as well to confirm the process. It may also have different firmware version on it, i'll take a look.

I'm hoping to explore options between the stock ROM with a few troublesome apps stripped out / extra permissions available via root, versus replacing with a GSI, given folks' reports above that treble check looked good.... but it's been maybe 8 years since I've had any android devices to mess with, so I'm relearning everything as I go here.

Anyone have advice on ROMs or requests on things they'd like to see tried?
[Google Home] cmccambridge:
Successful root!​

Took a few false starts, and not yet verified on my vanilla second device... so this would benefit from further refinement. This method mixes together two guides:

Previously linked method for sideloading apps on the Smart Clock 2: https://xdaforums.com/t/guide-installing-android-apps-on-the-lenovo-smart-clock-2.4393271/

This guide for rooting a Mediatek device, demonstrating usage of mtkclient and Magisk: https://xdaforums.com/t/root-mediatek-devices-new-method-works-for-imei-erased-phones-too.4547795/

Process:

Solder on to the USB port to connect to a host machine.

Extract the stock boot.img (and IMHO every other partition as well as a backup...) using mtkclient.

While you're here, unlock the bootloader. Could also do it at step 8.

Set up the device with Google Home and the screen reader based sideloading technique. Get access to Developer Mode and enable USB Debugging.

Transfer your boot.img to the device via ADB

Install Magisk on the device, and use it to patch your boot.img

Transfer the patched boot.img back to your host.

UNTESTED: Using mtkclient, wipe userdata, metadata, md_udc. (NOTE: I have not tried this exact step! I instead left userdata intact, and caused a boot loop into recovery after the following step, and I used Recovery's factory data reset to wipe the device... Don't be me: Spoiler content hidden.)

UNTESTED: Using mtkclient, write the magisk_patched_... boot partition, and an empty vbmeta. (NOTE: I have not tried this step! I instead booted to fastboot and used fastboot to write the boot partition and then reset the vbmeta, following Magisk's installation instructions.)

Set up the device a second time with Google Home and the screen reader based sideloading technique. This time when you install Magisk, you'll be greeted with "Your device needs additional setup for Magisk to work properly. Do you want to proceed and reboot?" Do so...

You're in!
[Google Home] Syco54645:
This is great news, nice work. It seems we may finally be able to remove the google assistant with what you have done. I have a clock but have not opened it yet. Do we know the pinouts for the pads on the bottom of the clock, when assembled that is. I would like to try this with pogo pins and breadboard.
[Google Home] bj00rn:
Awesome job! Will give this a try once I get a pogo connector sorted. Could you please confirm that the pinout is correct below.

Any luck on disabling the built in assistant service? Gesture navigation/proper launcher etc
[Google Home] cmccambridge:
Yes! This is the correct orientation. The DP signal should be closest to the corner, as you have it.

For the USB interface:

Board marking	USB pin	Typical USB wire color
DP	Data+	Green
DM	Data-	White
GND (use either, they’re joined)	Ground	Black
VBUS	5V	Red
DC 12V	not USB	—
DET	not USB	—
VBAT	not USB	—

Or looking at it AS SHOWN IN THE PICTURE ABOVE, with the wide side of the case horizontal and the connector at upper left:

DP / Green	DM / White
GND / Black	GND / Black
VBUS / Red	?? DC 12V
?? DET	?? VBAT
[Google Home] bj00rn:
Followed in the footsteps of @cmccambridge and successfully rooted device!

Next up is removing the lenovo stuff and assistant core. Maybe a quick stop with mitmproxy to try to find out where lenovo pulling its OTA firmware from and what "usage data" is being collected by their "mdmClient".

BONUS: Managed to hotglue together a purpose made frankenstein style "dock" using the pogo connector (https://se.rs-online.com/web/p/pcb-headers/7020461) and a few scavenged parts. The 12V rail really made things interesting... Someone more technically gifted please make an STK so i can send this beast back to into the abyss.

ROOT steps:

1. Download `mtkclient`

2. Did the whole sideloading shennanigans. Enable developer settings + usb debugging to get adb working, download and install ´magisk´ app.

3. Remove power from device

4. Connect usb using pogo or soldered connections.

5. Plugin in power cord while holding both Vol+ and Vol-. Device will boot to a blank screen. After a few attempts i managed to get mtkclient to connect, either my connection is flaky or the process seems a bit flawed.

6. Followed guide at mtkclient https://github.com/bkerler/mtkclient#root-the-phone-tested-with-android-9---12, with the addition of dumping all partitions for backup purposes. Make sure you pulled the magisk patched boot.bin/img BEFORE unlocking bootloader or it will be lost to factory reset. The guide has everything we need in there.

7. Boot the device again with Vol+ and Vol- pressed.

8. Flashed patched `boot.bin` and `vbmeta.img.empty` using mtkclient guide

9. Reboot the device and do the whole sideloading thingy again to install magisk and complete setup. Remember to disable OTA auto update! Reboot device.

10. Success!
[Google Home] cmccambridge:
Huzzah!!

Very nice work @bj00rn - I haven't gotten time to pick that investigation back up yet to get rid of Assistant... thanks for saving everyone the research time :-D Root paid off, right there!

Do the volume up/down buttons still work as buttons? Like, can you still see input from them if you use Key Mapper? Or do we have to figure out now how to restore them?

Long-term I'd like to find a replacement overlay for brightness and volume if I can, but far more important to me to remove assistant first!

(Note FWIW: you do not need to supply 12V to that pin in order to perform the root procedure- I've only connected VBUS (5V), GND, DP, and DM, and working just fine)

I think the whole process is just very timing-sensitive... the bootloader and preloader USB serial devices are only present for a brief window of time, which Windows needs to recognize and initialize the proper driver, all while in one of the narrow "listening" periods for the python and UsbDk tools (while the dots are ticking past?)

If it's helpful to anyone following along, I've used NirSoft's USB Log View to monitor which USB serial devices are coming and going- if the preloader port unplugs without mtkclient connecting, for example, then I know to yank the power and try again.
[Google Home] bj00rn:
Yes they work fine as buttons. But their default behaviour of changing volume is gone, which is pretty nice since we are remapping the keys anyways.

The magisk modules are perfect for this. Apps can easily be restored just by turning off the generated module and rebooting the device.

Overlay and some kind of dock/drawer would be nice if we could find. Other stuff that would be awesome:

Gesture navigation. At least swipe back would be nice.

Wireless ADB. Device is running Android 10 and should at least in theory support wireless adb, however the option is missing in developer settings. I tried setprop service.adb.tcp.port 5555 but adb is unable to connect and nmap shows no open ports on device.

Auto screen orientation is upside down for portrait mode. Using a third party app to force orientation mapped to key combo for now.

Replace/upgrade webview.

Getting access to OTA channel for updates (however unlikely since device is EOL and last update is years old). Will updates be _downloaded_ to the device storage even if auto update is turned off? Im guessing these are needed in order to do magisk again and flash to device according to magisk docs. I did some digging into requests to OTA server and from the looks of it credentials are provided.

Some less intrusive Clock app replacement so that the device can serve it's original purpose

Nice. On Linux the process was pretty straight forward though it took a few attempts. Using the mtk gui made it easier to understand what was going on.

I made the assumption that the dock supplies power on that pin in order to power the wireless charger on the dock. My soldering skills suck and i had no proper connectors so I ended up soldering a stripped 28AWG USB cable straight the PCB :). Didn't measure though, so maybe it's just used to power the device itself.
[Google Home] gfluf:
Just made this account to thank @cmccambridge and @bj00rn. I messed around with mtkclient, but reading/writing most partitions would just fail at 50% progress. If you hadn't posted your steps I would still assume that this just won't work as I expect it to.

The actual problem was flaky contact due to the makeshift Frankenstein adapter I soldered. So after also directly soldering an USB cable to the PCB and ordering some pogo pins, I now have two fully rooted and (mostly) functioning devices.

So thank you for the motivation to continue :)

To enable gesture navigation I used Fluid Navigation Gestures. Although you cannot grant the permission to display over other apps via GUI, it still is possible to do so via shell/ADB. I used the following command and now the app works without any issues:

pm grant com.fb.fluid android.permissions.SYSTEM_ALERT_WINDOW allow

Has anybody managed to rebind the volume keys to their original purpose? Using Key Mapper doesn't work as granting the permission to modify the DnD-State fails and cannot be done using ADB.

I could not find an actual way to enable wireless ADB, but wirelessly connecting to ADB worked for me. Although you have to bootstrap the connection via USB:

# while connected via USB:
adb tcpip 5555
# USB may be disconnected now
adb connect $SMART_CLOCK_IP:5555
# from here on all usual ADB commands should work
adb devices
adb shell

Currently I'm trying to find a solution to get the microphone working as good as it was before. Since removing the Google/Lenovo stuff the microphone level is extremely low and the recordings sound distorted. Something to the likes of a proximity sensor seems to be involved as the level of the recorded/played audio rises as soon as I hold it up to my face.

Does anybody have the same issue?

The intended use case for these devices is adding them as satellites to my Rhasspy setup to allow using voice commands for home automation . At the moment it doesn't even register that I'm talking at all.

Cheers :)
[Google Home] bj00rn:
More progress! Replaced the outdated SystemWebView with BromiteSystemWebView​

Finally some decent CSS support!

Steps:

* Install magisk module to add Bromite to supported SystemWebViews https://github.com/arovlad/bromite-webview-overlay/releases

* Install BromiteSystemWebView https://www.bromite.org/system_web_view

* Developer Settings -> WebView implementation -> Bromite

Wallpanel using built in SystemWebView

Wallpanel using BromiteSystemWebView

@gfluf welcome aboard! Happy to hear you got it sorted. Nice find on wireless adb. There might be an option to persist tcp across boot too. But im guessing its better to leave ADB over USB in case something breaks and I need ADB.

Strange findings about the microphone. Maybe the mic is in some other mode waiting for "Hey google is picked up".. The device only has a light sensor as far as i know so presence detection sound unlikely.
[Google Home] bj00rn:
@cmccambridge measured 12V to ground pin and there is indeed 12V on it when clock is connected to mains 🔥🔥🔥. The clock can probably be powered through this pin as well,

@gfluf which apk are you using to record sound? did some experimenting with Audio Recorder. Seems that sampling rate for microphone is way off. The more i increase the sample rate setting in the app the less slow-mo it sounds. Still off tough. Seems to be some configuration issue with the sampling rate.

Edit: @gfluf Sound recording seems to work _IF_ stereo is chosen in "Audio Channels" in the above app. Which app are you using?
[Google Home] gfluf:
Thats one of the apps I used. Produces clean recordings using Stereo instead of Mono. Other apps without such settings (especially rhasspy_mobile) still fail to record properly. I suppose somehow it must be possible to globally set the microphone to record stereo audio. Can't wait to have this working without the annoying assistant randomly interfering.
[Google Home] bj00rn:
There is probably something off here. Im pretty sure th device carries

Seems that Rhasspy if is requesting default format in their code. Maybe an option in the app to select format would be a way forward. Might be a tough sell though since the device is clearly misbehaving..
[Google Home] gfluf:
I'm on this, but due to holidays I'm a bit time-limited and had no chance to actually build and test the changes. If it works I'll see whether I can produce an acceptable PR.

Still, the best way would probably be to replicate whatever the original setup does to manage this. Seeing how "regular" Android variants behave (maybe via GSI?) would surely also be interesting.

I'll report back in the next days after I had some time with my dev machine.

Edit: This is probably nothing new, but wireless ADB can be activated quite comfortable using eg. this app (WADB). No bootstrap via USB required.
[Google Home] bj00rn:
Good!

Filed an issue at https://github.com/Nailik/rhasspy_mobile/issues/326 too, dev seems forthcoming.

I gave compiling the project a shot but gave up since im no android dev :-(.

I gave up on WADB ant went with SimpleSSHD instead of ADB, nicer and safer too.

I made some progress on getting the volume buttons to work!
[Google Home] bj00rn:
Managed to get volume buttons working​

EDIT: magisk_overlayfs now supports mouting system as r/w

From what i understand, the problem boils down to

1. Keymapper needs permission ACCESS_NOTIFICATION_POLICY

2. The device is "managed". Google assistant is still device admin even after being "removed" by magisk.

3. On managed devices the ACCESS_NOTIFICATION_POLICY cannot be assigned

4. An active device manager cannot be removed (unless testOnly=true) is specified in it's manifest.

dpm remove-active-admin: Disables an active admin, the admin must have declared android:testOnly in the application in its manifest. This will also remove device and profile owners.

Workaround

Modify /system/etc/device_policies.xml and /system/etc/device_owner_2.xml to specify keymapper as device owner.

Steps

1. Install magisk module https://github.com/HuskyDG/magisk_overlayfs to mount /system partition try to mount /system as r/w.

Reboot device

2. Unfortunately r/w mounting will fallback to read-only because /data partition type is unsupported by overlayfs. But we still end up with an upper directory which can be used to overlay files in /system at boot time.

3. Create etc directory in upper system upper dir

adb shell
cd /data/adb/overlay/upper/system
mkdir etc

4. Pull device_policies.xml and device_owner_2.xml using adb

adb pull /system/etc/device_policies.xml
adb pull /system/etc/device_owner_2.xml

5. Edit files and replace google assistant with keymapper package like so:

device_owner_2.xml

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<root>
<device-owner package="io.github.sds100.keymapper" name="" component="io.github.sds100.keymapper/.system.DeviceAdmin" userRestrictionsMigrated="true" canAccessDeviceIds="true" />
<device-owner-context userId="0" />
</root>

device_policies.xml

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<policies setup-complete="true">
<admin name="io.github.sds100.keymapper/.system.DeviceAdmin">
<policies flags="16" />
<strong-auth-unlock-timeout value="0" />
<cross-profile-calendar-packages />
</admin>
<lock-task-features value="16" />
</policies>

6. Push files to /data/adb/overlay/upper/system/etc /system/etc

7. Reboot device

8. Mapping volume keys will now work since Google Assistant is no longer device owner.

Maybe there is a proper way of doing this..
[Google Home] cmccambridge:
Ahhh that's fantastic! Bit of a pain in the neck, but great to have the option. I was stuck on that same permissions problem for KeyMapper last I poked at this...

Bromite webview was a very solid upgrade as well. Funny enough I noticed the CSS bugs on the exact same weather clock card in my Home Assistant dashboard in WallPanel :-D. Lovely to have that sorted.

Brightness

I am also still struggling a bit to get brightness controls sorted out - at minimum brightness, e.g. with the WallPanel clock screen saver showing, the screen brightness seems to "waver" in an unsteady fashion. Do you all experience that? Not sure if it's overly optimistic to dim that low and they're all going to flicker a bit, or something specific to my unit... I'm hoping to have it unobtrusive enough to be always-on in the dark, yet bright enough to work with if I wake up in the night or much brigher to be useful as a clock mid-day.

I also find that trying to open the Brightness settings under Display crashes the Settings app... perhaps I've De-Bloated one too many of the in-box APKs...

3D Printed Stand

I'm currently halfway through modeling a 3D printable stand for pogo connections that folks (and myself going forward) can use. I've modeled the bottom of the clock itself, and will next model a stand that mates with it:

BUT, I've only got on hand some generic "needle" style single pogo pins, which I plan to make do with for this one-off adapter. I don't have the fancy 2x4 grid that you linked earlier in the thread @bj00rn - did you indeed land on this exact part? https://se.rs-online.com/web/p/pcb-headers/7020461

If so, I can try and model a second stand option with a spot for that specific part to rest... what would you need beneath it in terms of space/clearance to be useful?
[Google Home] bj00rn:
Great minds think alike :-)!

I have not expreicenced any flickering. Will keep an eye out. Does it flicker with auto brightness turned off? I.e is the flickering caused by the light sensor or the screen.

Also, read somewhere that the dimming (or the screen)might be a bit wonky on the blue versions compared to the gray. You might want to enable MQTT sensors (at an high interval) and see whats going on with the light sensor.

Was like that before as well. Toggle auto brightness worked but tapping brightness settings crashes settings.

Sound great! Yes i have the exact part no 813-S1-008-10-016101. A=7, B=4, N=8 in the below schematic. Im really not good at these things. From the looks of it the entire connector height fits inside the slot, a few extra millimeters of housing below the plate to house the cable would probably suffice.
[Google Home] cmccambridge:
Successful 3D Printed Dock​

Took a bit to finish the model since I've had limited free time, but here's what I came up with: Lenovo Smart Clock 2 DIY Programming Pogo Pin Dock

TL;DR: If you have access to a 3D printer, pogo pins, and are willing to do a little wiring to build the dock, you do not need to open the clock to gain access to the USB interface!

See the Printables page for more info & photos... short story: the parts fit a little loosely together but they fit the clock really well and the interface I'm using (0.7mm "needle" style pogo pins) works great! I won't have to open or solder on to any of these in the future :-D

I attempted to design a part that's compatible with that exact Preci-Dip connector, based on the schematics above. I gave it zero clearance- just exactly copied the dimensions shown, hoping that it would press fit snugly. If not, may need to sand down the 3D part or glue the connector in place :) ... took my best shot without the part in hand to measure. I generically opened a cavity below it to hopefully allow enough access... you'll have to test and let me know whether it worked!

Good luck! Let me know any feedback or if folks have questions!
[Google Home] bj00rn:
Looks great!

Thanks for making a custom version for the Perci-Dip. I will give it a try!
[Google Home] Syco54645:
My pogo pins will be here today. I will let you know how it goes. I have already printed the dock so just a waiting game. I did shorten the legs a bit though.
[Google Home] Syco54645:
Well it worked. Nice work @cmccambridge. Going to glue this up and continue on with rooting.

edit: I connected a micro usb break out to mine and printed a case for that then just glued it to your dock. works perfect and should be around for many flashes.
[Google Home] Syco54645:
How did you get this working? I have tried for over 30 minutes and it still will not connect.