Google could have taken the same approach as Microsoft always did since the MS-DOS days and require specific hardware expectations.

Android solved a very different problem than iOS. It has compromises and benefits (that iOS has enjoyed by proxy) in doing so. The OS that we know today is the combined knowledge of many OEM customizations. The hardware of a vicious battle between many vendors. The screens and designs the result of an endless tug of war. And again, Apple has enjoyed the fruits of these.

But saying "If only they..." is seldom from a place of reason.

Apparently no one at Google ever read PC hardware specifications from Microsoft like "PC 97 Hardware Design Guide" or "Hardware Design Guide for Microsoft Windows 95", among a few other hardware guides from them.

https://www.amazon.com/Hardware-Design-Guide-Microsoft-Profe...

https://www.amazon.com/Hardware-Design-Guide-Microsoft-Windo...

Of course the Windows Phone attempted at it failed, because by the time Microsoft tried to apply the same rules as they did on the PC hardware, OEMs already had the Android wild west to play with.

Microsoft hit update handling for Windows Mobile spot on. A 2014 Windows Phone today[1] is a safer bet if you value security than any Android on the market right now. May not run the apps you want, but it is going to have the latest security updates.

[1]My Lumia 929 currently is running Windows 14393.1593, released August 8th, 2017. I can safely expect to receive the next update on September 12th.

When Windows Phone 7 was released (this is ignoring that Windows CE was around for about a decade before, giving Microsoft a massive headstart), Android had about 18% of the market. Microsoft leveraged their enormous base of desktop developers, pulling them through various failed initiatives, to get them developing for Windows Phone. Android started effectively from nothing.

In the context of actual history your post is simply surreal.

2 - Android 7 has currently about 13% acquisition after one year

3 - There is currently no obligation for OEMs to provide updates

4 - Given the failure of security updates, only being delivered to flagship devices, I believe Google will ship them directly when they actually do it.

2 - Right, this is something Treble will attempt to solve.

3 - Which is why Google is making it as easy as possible for them to do so, right down to actually pushing out the updates for them.

3 - I would really like to be proven wrong here. Still waiting for my Android 7 update on a newly bought device.

For example, something I was excited to see is in the updated documentation on source.android.com with regards to how they recommend developing kernel branches alongside devices: https://source.android.com/devices/architecture/kernel/modul...

Basically, one of the issues that's plagued OEMs in the past is the fact that each SoC vendor (e.g. Qualcomm, Samsung, ARM) would not only have a kernel for each SoC, but each OEM device using that SoC would be another branch on that SoC-specific repository. This would then be compounded by the OEMs having their own kernel repositories that pull from the device-specific branches of a SoC repository, and bug fixes from OEMs would have to trickle back upstream to the vendor repository before making them back to other device-specific kernels.

The new proposed model would see a single kernel soruce for a given SoC, and device-specific changes would come in the form of kernel modules, config overrides, and device tree overlays. They are also strongly recommending SoC changes to the kernel be upstreamed to mainline Linux, which would greatly ease porting to newer kernels in the future.

It isn't the first time that Google does recommendations to OEMs.

They also did recommendations for security updates. An advice that OEMs only follow for the customers that paid the big bucks for the flagship devices.

So unless they actually provide requirements instead of recommendations, nothing will change for consumers.