additional meis meiing meifully meihapsulating meibe (@mei)

Sven Slootweg, ("still kinky and horny anyway") @joepie91@slightly.tech

2w

yeah so that whole "google is gonna lock down android in 2027 thing, degoogle your phone now" thing

so are any of you working yet on actually making that possible for anything that isn't 10 high-end models from 5 western brands?

or is everyone just expected to drop $500+ on a new phone and add their old phone to the landfill as yet another piece of e-waste?

(and save me the "well technically some low-end models are supported" spiel because if that's your response then you have not understood the point I am making here)

#android #degoogle

❤️1

29

1

2

1

Sven Slootweg, ("still kinky and horny anyway") @joepie91@slightly.tech

2w

oh, and you can also skip the "but that's a lot of work, it's really hard! every phone needs to be dealt with differently! you can't just trivially add a device to the list!" excuse that people invariably raise whenever I call this out.

I know it's hard, that's why I'm asking whether any of you have been working on that yet

❤️1

4

0

1

Sven Slootweg, ("still kinky and horny anyway") @joepie91@slightly.tech

2w

I am already growing tired of the large amount of "well this rom supports tens of devices!" and "well this works for me" replies

I DO NOT CARE, THAT IS NOT WHAT THIS POST IS ABOUT, READ IT AGAIN

2

0

Sven Slootweg, ("still kinky and horny anyway") @joepie91@slightly.tech

2w

like I don't know how much clearer I can make it that I understand the android rom landscape perfectly well, that I do not need explanations, that I have not 'misunderstood' or 'overlooked' something, and that the point here is to call out a systemic failing of the degoogling crowd which you are a part of if you respond by trying to explain how it's fine actually

#android #degoogle

2

0

Sven Slootweg, ("still kinky and horny anyway") @joepie91@slightly.tech

2w

simply put, if you do not see the problem I am describing then you are not looking and listening hard enough

1

0

Sven Slootweg, ("still kinky and horny anyway") @joepie91@slightly.tech

2w

okay, so here's your concrete benchmark.

a hypothetical friend of mine would want to work on making degoogling possible for more phones. yes, actually hypothetical. they have some mild experience with programming, but are by no means an expert.

what they need to get started is a step-by-step guide of the process of porting a rom to a device, a suboptimal device whose manufacturer doesn't publish kernel sources (properly). a guide that explains the high-level process, how all the steps relate, and that either provides or references sources for learning the details of the individual steps. from zero to capable, basically. it's okay for the work itself to be complicated and extensive, as long as it's guided.

the device is going to be weird in some unexpected way, so they also need some kind of community in which they can ask others for help in figuring out those issues. one that isn't going to be toxic, judgmental, or in some other way unhelpful because they're a beginner.

finally, they're one person (at least for now), so they're going to need tools that automate a bunch of the grunt work. they don't need to be fully automated, it's perfectly fine to need to be involved in operating them, but they should eliminate most of the tasks that don't strictly need human involvement. those tools need to be findable from the guide.

these are the bare minimum requirements, not the optimal ones. just the minimum viable for onboarding new folks who aren't "deep into it". can you provide all of these, without caveats or "well it's technically not quite that, but..."?

if yes, do provide the link here because I expect that quite a few people would be interested.

if no, then you now know why device support is such an intractable and seemingly impossible problem in custom android roms, and you have work to do.

#android #degoogle

2

1

0

Irenes (many) @ireneista@irenes.space

2w

@joepie91 we don't think that's feasible in Google's architecture. it's too big, there are too many topics such a guide would need to cover, it would be more of a five-year program of study than a how-to. we should be looking outside Android for the future of phones.

1

0

Irenes (many) @ireneista@irenes.space

2w

@joepie91 not that the problem you identify is any better on the pure-Linux front, of course, but at least we see a path that way, you know?

1

0

Sven Slootweg, ("still kinky and horny anyway") @joepie91@slightly.tech

2w

@ireneista I'm not expecting the guide to cover how every single thing about how android works, to be clear, just to explain the parts of the process of 'getting a custom rom running on a mystery device and working out how to fill in the gaps'. all the weird permutations, that's what the community part is for

1

0

Irenes (many) @ireneista@irenes.space

2w

@joepie91 right, yes, it makes sense to want in the abstract

1

0

Irenes (many) @ireneista@irenes.space

2w

@joepie91 the thing is we, like, have 40 years of knowledge on programming and a fair few of those years are on low-level stuff and we couldn't write that guide, because we only know about 10% of the topics it would need to cover for the very base, minimum functionality of making things boot at all

1

0

Irenes (many) @ireneista@irenes.space

2w

@joepie91 so we do feel like we are at least qualified to say that the architecture is too big. we're not just offering that opinion from a distance or in an uninformed way.

3

0

Sven Slootweg, ("still kinky and horny anyway") @joepie91@slightly.tech

2w

@ireneista this does feel like it is assuming a single author, though. there are evidently people and groups who can complete this process (or we wouldn't have custom roms), and so there is some grouping of people who can produce the relevant knowledge, and what I'm thinking of is more a collaborative effort by said grouping to produce such a guide.

that may well take the form of a wiki or something else non-linear, but that's an implementation detail. the important part is that this knowledge is currently either 'locked up' in people's heads, or scattered around the internet, and it's in desperate need of some organized, structured documentation process by those who know how to navigate these waters.

1

0

Irenes (many) @ireneista@irenes.space

2w

@joepie91 we of course encourage collaboration, no matter what, collaboration is a good thing

why does Android have to be the target? is there some reason the additional work of that is, like, worth it? keeping in mind that the purported UX benefits really go away when none of the animations work properly or any of that, which is the case right after bring-up

2

0

Sven Slootweg, ("still kinky and horny anyway") @joepie91@slightly.tech

2w

@ireneista quite literally: because those are the phones that people have.

like, even if you were to run something not-android on those devices, that wouldn't change that you need to interact with - and probably pick apart - the android installation that is already on there in some way.

1

0

Irenes (many) @ireneista@irenes.space

2w

@joepie91 you don't have to run Android on them. that's all we're advocating for. you do have to subvert the bootloader to load your own thing instead of the stock thing, yes, and there are a few ways to do that and they all suck and give less security than you'd have on a device meant to run an arbitrary distro from the start, but it's not really the hard part.

1

0

Irenes (many) @ireneista@irenes.space

2w

@joepie91 you may overestimate the amount of picking-apart of the manufacturer Android distros that is involved in this work.

1

0

Sven Slootweg, ("still kinky and horny anyway") @joepie91@slightly.tech

2w

@ireneista from my perspective, the process involves picking apart the vendor images, finding a way into the bootloader (potentially involving finding exploits), extracting hardware-specific drivers and mechanisms from said vendor image (which likely involves more than just copying over a file, due to vendor kernel patches and such), and (partly or fully) reverse-engineering those to port them to whatever is to be run on the device after that, whether it is Android or Linux or something else.

all of these steps are an integral part of the process of liberating a device in some way. I expect that a lot of work will be in the reverse-engineering of the drivers, and understanding the android-specific bits of said drivers.

this is why I believe this whole thing to be viable with the right tools and training; each of these steps is highly specialized and some of them are very slow, but each is also tractable with the right tools and support network.

whether those bits and pieces then get turned into Linux drivers or patched into some custom Android ROM, I have no opinions about that - the choice there is not relevant for whether the device can be liberated. that is also why I do not believe the architecture of Android itself to be a meaningful hurdle in this.

1

0

Irenes (many) @ireneista@irenes.space

2w

@joepie91 and then it involves a ton of additional Android work after all that. again, using Android does us no favors.

1

0

additional meis meiing meifully meihapsulating meibe @mei@amazonawaws.com

2w

@ireneista @joepie91 As someone who first ported postmarketOS (pure-Linux) to a unsupported device when she was ~14

, I can definitely agree that porting Android is a much harder task. You need like ~150GB free diskspace and a loott of compilation time. Then many things will probably not work, even without ever replacing the vendor kernel - something that can usually be skipped.

If you have these resources and time to play with Google's build systems you can probably make it work. But it's a massive investment for 1 device every few years..

postmarketOS is actually pretty straightforward! As long as you aren't exploiting the bootloader, anyway. Most modern phones have been good about that IME. But this is far from a fully-featured phone for most devices, in terms of stuff like "all cameras work" or "I can actually do a phonecall". Even if we overcome that, banking apps and similar will necessitate an untampered device – something that is getting harder to spoof as the last devices not supporting hardware attestation are reaching EoL.

Having two devices for this purpose is most certainly a luxury. Building Android like a vendor would is time-consuming and requires wider skills due to needing to have a deeper understanding of the underlying technologies and patterns as you are sandwiched between two rolling targets: the vendor and Android.

Relative to that, postmarketOS is straightforward to get started with.

0

3

0