When you look into rooting or bootloader unlocking, one or more steps involve running some tool that isn't open source, or at least is primarily distributed as a binary of unspecified providence. You don't really know that the tools won't inject some unwanted software onto your device.
What would be a good way to promote transparency and trustworthiness of the alternative rom tooling? Or is there an alternative set that just doesn't jump out when searching for the tools?
I think the biggest problem is that most of those developers don't want to actually host things in a proper way, like a regular open source project. Everything is on XDA, there's no proper bug tracking, no hosting, etc.
What's even worse is that they don't work together. If all all ROMs are based on AOSP, why can't they work together to get device compatibility? For example, why can't Lineage use Omni's code to support 'potter', and Omni use Lineage to support 'gemini'?
And then you have all the single developers working on their own devices. Why can't Lineage pull their work, do basic code review, and publish them as "beta" (and you get free beta testers)?
Despite being based on AOSP, omni/lineage/etc all have pretty different features, so usually it takes a nontrivial amount of effort to go between the two (although it's definitely less effort than starting from scratch)
Most devices within the project are maintained by single developers - the difference is that official devices have been submitted to us and have everything working.
We don't blindly support devices (even as "beta") because we have no way of verifying that everything actually works (e.g. blobs that depend on an old C library ABI can't really be detected before runtime, afaik). Shipping stuff that's broken is something we'd like to avoid. The idea is that when you download a LineageOS build from lineageos.org you know that it'll work flawlessly (that may not always be the case, but it's the goal :P)
>Despite being based on AOSP, omni/lineage/etc all have pretty different features, so usually it takes a nontrivial amount of effort to go between the two (although it's definitely less effort than starting from scratch)
I understand, the same way that Firefox and Chrome are very different, yet work on the same kernel, or are the differences between Lineage and others that deep?
So for example, Omni has athene up and running on Oreo, while despite officially being maintained (with three maintainers at that), according to Lineage OS' code review, it hasn't been worked on since last July.
So the way I see it (coming from a dev, though not a ROM dev): Android has multiple layers. It has hardware-dependent code (such as the kernel) and hardware-independent code (such as bionic or Java), sort of like in Desktop Linux you have the kernel and X, and there's bash, gnome and Firefox.
So why can't (I know how that sounds coming from the outside ... ) you take their hardware code (the kernel and whatever the Android equivalent of X is) and build on top of that? Is the whole system that integrated?
On the other hand, now that Treble officially separated the two, will it be possible to, for example, flash Omni and then flash a lineage image on top of that?
>We don't blindly support devices (even as "beta") because we have no way of verifying that everything actually works
But does every Debian maintainer (of a userspace program like, say, MySQL) have every combination of hardware? You just assume that the kernel and libc are a reliable abstraction and go from there. Is that impossible on Android?
>So the way I see it (coming from a dev, though not a ROM dev): Android has multiple layers. It has hardware-dependent code (such as the kernel) and hardware-independent code (such as bionic or Java), sort of like in Desktop Linux you have the kernel and X, and there's bash, gnome and Firefox.
Yeah, that's pretty much it.
>So why can't (I know how that sounds coming from the outside ... ) you take their hardware code (the kernel and whatever the Android equivalent of X is) and build on top of that? Is the whole system that integrated?
We could - and it would definitely be a good start - but there would be changes necessary because e.g. our extra bits are implemented differently, maybe our "device-independent" bits are missing some commits that Omni has that fix support for some OEM driver - before treble, Android's hardware-dependent code and hardware-independent code were often both modified by OEMs/SoC manufacturers in order to fix issues on their platforms/add extra features. So Omni might have some fixes that we don't have, and vice versa.
>But does every Debian maintainer (of a userspace program like, say, MySQL) have every combination of hardware? You just assume that the kernel and libc are a reliable abstraction and go from there. Is that impossible on Android?
It's much harder on Android, because there's so many blobs built against previous platform releases (often with extra ABI changes from the OEM added on top). That means we can't assume that the ABI is consistent: for instance, we've had nasty bugs in proprietary binaries caused by AOSP adding fields to structs. Whereas on Debian, everything's kept in-step, so they don't end up with ABI mismatches all over the place.
Hopefully with Treble, a lot of this will change - so the idea of a "universal Lineage image" might be possible.
Also, don't use Chainfire's SuperSU in 2018 regardless. It's owned by some Chinese company that's not very reputable. The current trend is towards Magisk, an open-source root (and systemless /system) modification framework.
> or bootloader unlocking, one or more steps involve running some tool that isn't open source
fastboot is open source. That's literally all you need to unlock the bootloader on a great number of phones. The vast majority of users don't need to root their phones, and doing so is a pretty big security hole for the users that think they need to.
On the other hand, your alternative is to stick with OEM/carrier OSes, which are quite obviously compromised for benefiting the OEM/carrier and not the user.
Many apps allow exporting their data without requiring root. There are adblockers that set themselves up as a 'VPN connection' on your device for filtering out ads, those do not require root.
Seconding DNS66. Another benefit over hosts file based ad-blocking is you can disable/enable it without having to restart, which is super handy for the occasional "is this site broken or is it my ad-blocker" sanity check.
Upon reflection, I suspect those localhost-vpn ad blockers have to reconstruct your ip traffic back into outgoing socket api calls, which can't work really well for non-web traffic.
I .. only learned about these ad blockers from this thread, so take everything I write with a healthy amount of table salt.
That said, as far as I understand this DNS66 thing only intercepts DNS requests (which yes, it needs to break apart and reassemble) and nothing else? That is - if you don't talk to a server that is part of the application's custom DNS server list or a DNS server given to you by your network configuration, then I'd expect this packet to bypass the VPN entirely.
Maybe someone who understands the Android VPN service thing a bit more can chime in and confirm?
What would be a good way to promote transparency and trustworthiness of the alternative rom tooling? Or is there an alternative set that just doesn't jump out when searching for the tools?