> all of which are closed down and locked experiences
That's not true. Many Android devices have an unlockable bootloader with explicit support for building the Android Open Source Project (AOSP) for the device. Nexus and Pixel devices are directly supported by AOSP without modification. It's the same codebase used to build the stock OS for those device. The stock OS on those devices only adds Google Play apps to the source tree, some of which replace AOSP apps. It doesn't contain any secret sauce changes to AOSP. Android engineers use the same Nexus / Pixel devices that are shipped to consumers as their development devices. You enable OEM unlocking within the OS from the owner account and can then unlock the bootloader via physical access using fastboot over USB, allowing images to be flashed via fastboot. Serial debugging can be toggled on and done via an open source cable design through the headphone port.
Other companies like Sony have emulated this by releasing official sources for building AOSP for their unlockable devices rather than only making the bootloader unlockable and leaving it up to the community to hack together support. However, I think it's only Nexus / Pixel devices where you get support for full verified boot with a third party OS (i.e. you can lock the bootloader again, and have it verify the OS using a third party key) along with the ability to toggle on serial debugging.
It's why the Android security research community is so active. You get the same sources / build system, development devices (Nexus / Pixel), debugging tools, etc. as an Android engineer working at Google. The only major thing you don't get is access to their internal bug tracker. Hopefully they'll move towards the Chromium model where most of that is public once embargoes are over.
Putting aside for the moment your comments about AOSP (the timeline on the slow closing down of the source branches is a great one, particularly as you now watch more of the code move into Google Play services and the AOSP core applications be slowly obsoleted), as the issue here isn't really about the source code (and I don't think that's the point you are making anyway), I will concentrate on looking at the status of Android as an open hardware platform.
I cover the Nexus devices when I give talks. While I haven't looked into the Pixel yet (and I know that I need to, as the arguments I am about to make for quality likely will have begun to change), I can tell you that effectively no one buys the Nexus devices (the market share for them is ~1% with a 1% margin of error), and they are not seen as high quality devices.
The reality of the Android market is that Samsung makes 98% of the profit, and the vast majority of flagship devices are being made by the handful of companies that put the most effort into locking down their devices. If you want the "high-quality phone"--the one with the good screen and the good camera and the fast CPU that can run all of the apps that you increasingly need in this day and age--you are not buying one of the random open devices.
Again, though: I admit that Google's attempt to retake the flagship market and compete with their hardware manufacturer partners with the Pixel (a device which specifically looked at having stuff like a super high quality camera and screen and such) might change things, but this is an incredibly new development in the grand scheme of these things.
> The reality of the Android market is that Samsung makes 98% of the profit, and the vast majority of flagship devices are being made by the handful of companies that put the most effort into locking down their devices.
You know you can buy an international Galaxy S8 and unlock the bootloader without any exploits, right? That part works the same way as Nexus / Pixel devices on the S8 variants that can be unlocked (i.e. not US carrier versions, etc.). The difference is that Samsung doesn't give you 100% of their OS sources especially on the day that they release each update and they don't support verified boot for a third party operating system. They also revoke the warranty if you do it, but they permit it. They explicitly implemented a standard unlocking procedure for their consumer devices and it's not in any way forbidden by the terms of use other than voiding the warranty, which is sad but not exactly unfair. Their attempt to void the warranty is not valid in everywhere anyway. They still often need to honor standard warranty requirements unless it's demonstrated that the user is at fault for what went wrong.
> Putting aside for the moment your comments about AOSP (the timeline on the slow closing down of the source branches is a great one, particularly as you now watch more of the code move into Google Play services and the AOSP core applications be slowly obsoleted)
I don't know what you mean about AOSP source branches being closed. It's not true. They still release the entirety of every stable branch they ship on the same day that it ships. There isn't any substantial delay and they haven't started doing incomplete releases of the AOSP sources. They don't make things as easy as they should be but things haven't really gotten any better or worse overall for AOSP. It takes more work to assemble the proprietary Qualcomm code from their factory images (see https://github.com/anestisb/android-prepare-vendor) than it did before, but most other things are better now.
It's also not true that any of the core OS in AOSP has been or is being obsoleted. They've stopped maintaining some of the user-facing apps like Calendar, Email, Music and QuickSearchBox and a few providing app-layer services like text-to-speech which all have other implementations available. There's nothing they have stopped maintaining that's critical enough to really matter. There's no shortage of music apps and there are other Android text-to-speech apps, so the AOSP PicoTTS being unmaintained beyond them keeping it building / running as it did before doesn't really matter to anyone. They haven't stopped maintaining any core OS components. Many apps / components that are updated via Google Play and/or have proprietary Google service extensions are still properly maintained in AOSP without those extensions, like the Contacts, Dialer and Launcher apps. Below the application layer though, it's the same. Google builds the stock OS from the same source tree released in AOSP stable branches with their Google Play additions.
There's also the claim that code is moving into Google Play Services, but for the most part that isn't the case. Play Services has expanded but very little has been lost in AOSP. There isn't a movement of stuff to Google Play Services but rather they split out components into apps / components that they can update via Play (which doesn't hurt AOSP as they're still updated there) or they introduce new clients to proprietary server-based services. That's still what defines Play Services: clients to APIs provided by Google servers and out-of-band updates to components that are still maintained / updated in AOSP too. There are very few cases where anything has actually been dropped in favour of Play Services. I can think of a single example: voice to text. That's quite clear to anyone that has actually worked with it or used it.
You're speaking far outside your area of expertise based on anecdotes you've heard, rather than tangible facts.
> and they are not seen as high quality devices
Nexus 6 was as premium as Pixel devices, and the Nexus 6P was a quality device. Nexus 5X and 6P were the generation where Google started shipping good cameras, their own fingerprint reader setup, etc. not Pixels. Nexus 6 was a quality flagship device a year before then. There are plenty of non-Google devices that are 'open' in the same sense though.
> the vast majority of flagship devices are being made by the handful of companies that put the most effort into locking down their devices.
Not true. Vendors like Samsung sell plenty of unlocked / unlockable devices.
> If you want the "high-quality phone"--the one with the good screen and the good camera and the fast CPU that can run all of the apps that you increasingly need in this day and age--you are not buying one of the random open devices.
Not true for the reasons above. Your statements aren't based in reality.
> Again, though: I admit that Google's attempt to retake the flagship market and compete with their hardware manufacturer partners with the Pixel (a device which specifically looked at having stuff like a super high quality camera and screen and such) might change things, but this is an incredibly new development in the grand scheme of these things.
Pixels aren't a substantial departure from the Nexus 6 and Nexus 6P. Compared to the Nexus 6P, the SoC, image sensor, screen, etc. were all just moved ahead a generation. The build quality is comparable and in some ways the Nexus 6P was a nicer device: it definitely had nicer speakers, and
That's not true. Many Android devices have an unlockable bootloader with explicit support for building the Android Open Source Project (AOSP) for the device. Nexus and Pixel devices are directly supported by AOSP without modification. It's the same codebase used to build the stock OS for those device. The stock OS on those devices only adds Google Play apps to the source tree, some of which replace AOSP apps. It doesn't contain any secret sauce changes to AOSP. Android engineers use the same Nexus / Pixel devices that are shipped to consumers as their development devices. You enable OEM unlocking within the OS from the owner account and can then unlock the bootloader via physical access using fastboot over USB, allowing images to be flashed via fastboot. Serial debugging can be toggled on and done via an open source cable design through the headphone port.
Other companies like Sony have emulated this by releasing official sources for building AOSP for their unlockable devices rather than only making the bootloader unlockable and leaving it up to the community to hack together support. However, I think it's only Nexus / Pixel devices where you get support for full verified boot with a third party OS (i.e. you can lock the bootloader again, and have it verify the OS using a third party key) along with the ability to toggle on serial debugging.
It's why the Android security research community is so active. You get the same sources / build system, development devices (Nexus / Pixel), debugging tools, etc. as an Android engineer working at Google. The only major thing you don't get is access to their internal bug tracker. Hopefully they'll move towards the Chromium model where most of that is public once embargoes are over.