You weren't originally talking to me. I think you have the intent to push your views and you're willing to make lots of false claims to do that along with engaging in a discussion in a manipulative way. Not malicious intent, rather, an underhanded approach is being used.
Conversation
I mean, here you go again with misrepresenting the issues I've had with this long and extremely frustrating series of threads as far different. A nice summary of the problems.
You went out of the way to involve yourself and write up a huge series of replies before I was there.
1
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.
2
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.
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.
1
Show replies