Curiosity (stupidity?) got the better of me and I ended up awake until 2am fixing this last night on my Pixel 3a.
I was fortunate enough to have developer mode & USB debugging enabled, which allowed me to install some code to clear the wallpaper using the WallpaperManager [0].
Sadly it wasn't as simple as pushing the code to the phone and running a command to execute it. When the device boots, it would crash _almost_ instantly and reboot into recovery mode after attempting to show the wallpaper a few times. This meant I couldn't put my passcode in, which meant Android refused to run the application I made to clear the wallpaper.
The ADB (Android Debug Bridge) tool [1] lets you replicate user input for the connected device, so you can basically swipe the screen / enter keys from the command line. I was able to use ADB to swipe up on the lock screen and enter my passcode. This was a start but wasn't enough, as the crash was happening before the wallpaper deleting app could be started.
I figured the unlock process was taking too much time, and found out after Android 8 (Oreo) you can actually use ADB to change or remove your passcode [2], provided you know your existing passcode. After I removed my passcode I was able to reboot the device, and run a single ADB command to swipe up on the screen and delete that cursed wallpaper.
And no it wasn't worth it, but I enjoyed the challenge
Times like this are why it would be really nice for google to allow a root shell for developers when booted in recovery mode or something. Trying to fix this from userspace in the short window you have before the systemui crashes... what a silly avoidable nightmare.
You can root your phone, but then you lose SafetyNet which means that things like banking apps, etc. won't work. For "normal" developer access there's adb which does have some special privileges (nowhere close to actual root, but better than nothing), but using it to change screen background settings would be quite clunky. Even using the adb shell to delete the file would run into restrictions on general storage access that newer Androids have.
Magisk has an option to force enable passing SafetyNet, plus hide Magisk. If you combine those you can have root and still run banking apps and Google Pay like normal.
Magisk Hide is an unreliable workaround, since remote attestation of the running OS could be required at any time to pass SafetyNet. Even the author of Magisk Hide is well aware of this.
See this tweet chain from the Magisk author. It seems Google might enable remote attestation at some point like they did for a short period during this tweet, defeating MagiskHide.
To me adb was the last resort to make an old tablet of mine useable. That little bastard resisted all rooting attempts, and was filled with branded junk which made it slower than a dead sloth; luckily adb allowed me to remove a ton of "system" rubbish.
I think that depends on the phone and the root application used. My HTC is rooted with magisk and it claims SafetyNet is still in operation. I don't use my phone for much banking, but I've never seen any issues.
If stock recovery mode (or TWRP - not sure if it’s still a thing as it’s been ages since I last used Android) allows access to the file system you should be able to figure out and edit whatever configuration file controls whether ADB is enabled.
This requires a wipe in most cases to unlock your bootloader (if that's even possible for your phone, not all can be). At that point, you might as well just wipe your phone.
EDIT: Some phones also require you to unlock it in settings too don’t they?
It depends on what android version your phone had. You cannot flash TWRP on phones that came with 10 by default (there might be few workarounds). Mine came with 8.0 and I flashed it later.
I was fortunate enough to have developer mode & USB debugging enabled, which allowed me to install some code to clear the wallpaper using the WallpaperManager [0].
Sadly it wasn't as simple as pushing the code to the phone and running a command to execute it. When the device boots, it would crash _almost_ instantly and reboot into recovery mode after attempting to show the wallpaper a few times. This meant I couldn't put my passcode in, which meant Android refused to run the application I made to clear the wallpaper.
The ADB (Android Debug Bridge) tool [1] lets you replicate user input for the connected device, so you can basically swipe the screen / enter keys from the command line. I was able to use ADB to swipe up on the lock screen and enter my passcode. This was a start but wasn't enough, as the crash was happening before the wallpaper deleting app could be started.
I figured the unlock process was taking too much time, and found out after Android 8 (Oreo) you can actually use ADB to change or remove your passcode [2], provided you know your existing passcode. After I removed my passcode I was able to reboot the device, and run a single ADB command to swipe up on the screen and delete that cursed wallpaper.
And no it wasn't worth it, but I enjoyed the challenge
[0]. https://developer.android.com/reference/android/app/Wallpape...
[1]. https://developer.android.com/studio/command-line/adb
[2]. https://android.stackexchange.com/a/194779