I think what you were doing is inherently hostile from the start: showing up in random threads to peddle a bunch of dubious claims and misinformation to push your views.
Certainly does a good job at causing stress and disruption of work.
Conversation
You jumprd in on me sharing my opinion that Android is continuing to head in a difficult to audit and maintain direction.
This is an informed by me spending hundreds of hours trying to port devices and automate builds in spite of Google not investing in testing AOSP anymore.
3
1
> You jumprd in on me sharing my opinion that Android is continuing to head in a difficult to audit and maintain direction.
It wasn't your thread. You jumped into a thread to go off on a tangent about that.
> not investing in testing AOSP anymore.
Huh? It's what they ship.
1
Google used to pay a dedicated person to build/test AOSP from source on all new devices. They don't now and this has slipped in priorities.
I know this because I literally met with an Android team manager and talked about it in Mountain View.
3
1
Many teams working on Android do AOSP first development. It's what they are primarily using and testing during development, and is what they ship on their own devices with the addition of their overlays. The normal AOSP stable tags are the stable tags for their own stock OS.
2
Yet it won't boot without stealing tons and tons of blobs and nonsense from the factory images let alone build signing etc. Tons of hacks are always needed just to get source+drivers AOSP working on their own first party devices.
They have not built ready-to-use AOSP in years.
1
1
That's not true, and again, you're confusing the state of AOSP (which is great) with the state of public support for others to build AOSP for Pixels (which is very poor).
1
The actual AOSP reference devices are devices like HiKey 960. Pixels are a Google product with partially open source device support code released as part of AOSP.
They use them as reference devices internally, and a substantial portion of the teams do AOSP-first development.
1
1
Pixels are not reference devices for others to use for AOSP development. They don't work well for that. You have to look way back for a time when Google's first party phones could be treated as AOSP reference devices. Nexus 5X was all around worse than a Pixel 4 for this too.
1
It's very clear that AOSP is intended to be used to target hardware under the control of the person doing development work, whether it's their own device or a device intended to be used that way. Pixels are not really intended to be used that way, and make many things difficult.
1
Using AOSP is very viable. It's very different using AOSP to target a device intended to be used by you for development vs. using Pixels. You have *3 years* of security updates for each of the major releases and you get device support code from your vendor(s) in a usable state.
So when a release like Android 11 comes out, it's a non-event and you can migrate at your own pace. Even without being a partner with early access, it's not much of a major issue. There's nothing to hack together or reverse engineer. AOSP isn't the problem at all.
1
Also, thanks to Treble, you can keep shipping AOSP updates including the major version upgrades without necessarily having support for them from the vendor(s). You can move to Android 11 while using Android 10 vendor support. Better to have it overhauled, but it's not mandatory.
1
Show replies