Quote:
@csdvrx You have the same problem.
I've updated yours and it is available at the same URL, size 30,920,854
|
tysm!
For now I'm still working on the early adb part: I don't want to take any risks until I understand exactly what's happening and why, since there're a lot of seemingly weird things and not just in the Onyx builds but in Android in general.
We have the same desire to remove useless cruft, but some of it seem present for good reasons we don't understand yet (here: pre Android 11 compatibility) maybe because these reasons are very obscure!
So our natural hacker tendency to simplify/streamline/improve (whatever you want to call it!) may play against us, as it did play against me during the initial problems I had with fastboot (the ones that I first emailed you about).
FYI, I've found similar oddities in the ADB part: based on my limited knowledge of Android, adb used to have a special mode that allowed adbd to be started early in boot, with full root etc given the possible limitations (ex: no auth during early boot) to maximize the chance you will be able to connect and regain control of your system if you did something bad.
Based on my limited understanding, that was gutted by google for security reasons, and some kernels may have removed support for some important flags so it's uncertain whether it can be brough back as it was before.
On top of that, they also moved the adb binary quite a few times (next to last in /system/bin/adbd, currently it's standing somewhere in /apex)
To make things worse, onyx still has init scripts that will use any adbd binary found in /system/bin/, which lead me to funny yet interesting problems. Yesterday I lost a lot of time chasing weird bugs because I wanted to provide CrazyCoder a robust early adbd solution in case they wanted to deploy the patched framework, because I was afraid of potential problems it may cause.
Right now I'm trying to understand why I have adbd started twice, once during the boot animation (by the time the 5th square get painted on my Air C) then closed and started again when android stards. Then I want to isolate what is causing each of the starts.
My goal is to have the "early" adbd be a root with no auth, then have the normal adbd be the normal one: this way, if you do something bad and your android can't start, you'll have full root access to fix things. But if your android can start normally, you won't leave a security hole (to my dismay, I've learned there's a load of malware aimed at rooted devices!)
But right now I have a weird problem where 2 adbd "coexist", which shouldn't happen... I'll have to make them use different ports, with different sysprop so back to square one and designing a solution!
All this to say I think we have to be extremely careful about our interventions: we should make them as surgical as possible, at least until we know the precise role of all the involved parts and therefore the potential consequences (and thus the tradeoffs) of the things we do.
That may cause some apparently needless complexity (ex: my initial desire to have the adbd in a chroot etc) but Android seems to be a pile of poor decisions with weird retrofitting for compatibility reasons, which makes the whole thing very brittle, and requires complex solutions for apparently simple problem to avoid problems (ex: if android can't start and adbd would only be started after android start... oopsies)
The example of apps crashing because mime types were removed from a jar IN WHICH THEY SHOULDN'T BE IN THE FIRST PLACE (!!!) is a wonderful illustration of the issues that run deep within Android.
Anyway, if you know more about how adbd and started and by what, please tell me: I'm currently focusing my attention on /system/etc/init/hw/init.usb.rc and the content of /apex/com.android.adbd/etc/