The sad thing is that back when 3.0 (Honeycomb) shipped, most of the 10" or so Android tablets included a full size USB-A port. But then came 3.1, and the introduction of the above permission, and basically the major selling point of said port evaporated (i have a Toshiba Thrive sitting here that i basically shelved after said change).

If we observe Windows tablets, with the MS Surface at the forefront, many of them come with a easily accessible USB-A port (I recall Gigabyte tried to sell a tablet that came complete with a ethernet port even, but i think that series has since been discontinued).

What worries me is that Google introduced this change to placate big media. Because around the same time they made the big announcement that people could now buy movies and music via the Android Marketplace (later renamed Google Play).

> Toshiba Thrive sitting here that i basically shelved after said change

You can access your media if you use a file explorer and media player which support the new API.

> If we observe Windows tablets, with the MS Surface at the forefront, many of them come with a easily accessible USB-A port

And all of the applications running on it can access all of your media. Life is easy when there's only one single flat security domain.

https://xkcd.com/1200/

It's not to placate big media, but to increase security, as others have pointed out.

But the bigger point is that I don't think it's just the USB port that limited Android's flexibility. Android was supposed to be a more flexible, more powerful iOS. That didn't play out in ways the average end user cares about.

What advantage does a A-port have over the current micro ports in a tablet? And now the new C port is slowly gaining more support, I bet the A-port will slowly vanish completely, or am I missing something here?

USB-A port = no fiddly adapters etc.

Counter-intuitively, those big fat USB-A sockets have a much lower minimum-cycle specification compared to Micro-B or USB-C ( 1500, 5000 and 10000 respectively ).

So the tiny, fiddly ports are more robust.

Don't worry, i'm sure folks would have also complained had they stuck with those ports and they broke.

> Android felt like a general-purpose OS that just happened to run on a phone.

And that was its big issue. They used the firmware model for a general purpose OS. This keeps Android from having the simple install models we've come to expect with Windows/some Linux distros/MacOS. I wrote a thing on this a while back:

http://penguindreams.org/blog/android-fragmentation/

Agreed, but my point was intended more in terms of what apps can do. Full access to USB, multitasking, users can install apps outside Google Play, a variety of hardware rather than just one or two models Apple deems good -- all these are advantages of Android when it comes to tablets, laptops or other devices to get work done. But the ecosystem hasn't evolved to take advantage of these, so the benefits are lost.

Note that Chromebooks are similar (and Android 7 adopts the update strategy of ChromeOS). There you have two system partitions, one in use and one on standby. A system update gets applied to the partition on standby, and on next reboot it becomes the used partition (unless the boot is deemed faulty).

BTW, event thought Chromebooks gets updates all the time the kernel and drivers are the same one as when they originally shipped. This means that older Chromebooks will not be able to run Android apps, as it is done using kernel provided containerization.

Are you sure about that? I've got a Samsung chromebook (Snow) from about 3 years ago, and yet...

     localhost / # uname -a
     Linux localhost 3.8.11 #1 SMP Mon Sep 26 02:48:53 PDT 2016 armv7l ARMv7 Processor rev 4 (v7l)
     SAMSUNG EXYNOS5 (Flattened Device Tree) GNU/Linux

Recently built kernel. Unless things have changed from a few years back (when I last played with it), there are multiple (3) kernel partitions in ChromeOS:

https://www.chromium.org/chromium-os/chromiumos-design-docs/...

...and you can manually select between them by using the "cgpt" command from the shell:

So on an ARM device, you could say:

     sudo cgpt add -i 6 -P 5 -S 1 /dev/mmcblk0

If I'm not mistaken, this would mean to set partition 6 (a kernel) with a priority of 5 (compared to other partitions at boot), successful flag set to 1 on mmc block device 0-- (the internal mmc, where mmcblk1 is the external sdcard). I think if that kernel fails, that flips the successful flag to 0 and it falls back to the next priority kernel on the reboot. But like I said, it's been a while so don't quote me.

See more here: https://www.chromium.org/chromium-os/chromiumos-design-docs/...

Also, if you weren't aware, to get into the shell:

     ctrl-alt-T
     shell
     sudo bash
     cgpt --help

if you play with cgpt, be VERY careful. Also, if you're thinking of replacing kernels or whatnot, be aware that on most (all?) devices, the partitions are signed, so you'll have to turn off any checks first.

Well it was Google's excuse for how only certain Chromebooks of a recent vintage would be getting Android app support.

Maybe they meant the major version number of the kernel wouldn't get an upgrade, though I suspect maybe performance/memory limitations are the real issue. It may be possible to backport whatever features are missing to an older machine's kernel and see...

Does every vendor have their own image, or is there one universal image for chrome laptops? If it's the former, can you just put a stock image on it, or does each vendor embed their drivers?

Every device has its own kernel and drivers, which is signed and verified. See:

https://www.chromium.org/chromium-os/chromiumos-design-docs/...

If you can unlock your bootloader, you can build your own version of chromeos and the kernel, but trust me, it's not as good. You'll have a chromium-based OS, not chrome based-- it's a lot like the difference between Chromium vs. Chrome in Linux, only affecting the whole OS.

I haven't done it in a few years, but I imagine that with the Android integration, even if it builds, you'll have more of a stock AOSP experience sans any Google cloud features. Good for freedom and privacy, but if you're bothering to replace the OS like that actual Linux may be a better call.

But if you go for standard Linux, you may run into issues with hardware support, especially graphics acceleration... just sayin'. The closed-source graphics drivers written for ChromeOS may not play friendly with Xorg or whatever.

Aside from potential issues w such blobs, I don't see any reason you couldn't unlock the bootloader and try updating your own kernel...

Yea I know a few people who attempted open-source (mostly; drivers are still usually closed) phones sans Google/Amazon stores and services. They'd use F-droid/K9-mail/OpenStreepMaps/OwnCloud, etc. They mostly work, but you do lose a lot of the android ecosystem. One of my friends gave up after a year and went back to the Play Store/Gapps because she started writing her own Android apps to make up for what she was missing and just didn't have the time for it.

I didn't realize ChromOS was in the same boat. That's really shit. In traditional Linux, a lot of drivers get merged right into the tree. Even for proprietary drivers/blobs, we have linux-firmware. For the most part, the initrd files on Arch/Debian/Ubuntu can load a lot of modern hardware.

I wish Google Android/Chrome devs would get their shit together and stop this individual build madness. An initrd full of drivers and linux-firmware do not take up that much space, and many phones now have the footprint of tiny laptops vs the old <8GB tiny flash roms.

Google wields a heavy hand with their (no-so-)open handset alliance (OHA). They can get manufactures to at least commit their blobs to a standard google-firmware package and keep a fork of their Kernel that builds all major drivers into a standard initrd package. Manufactures could always strip out all the crap for their custom ROMS, but this would allow AOSP to just run, out of the box, like Windows 10 or Ubuntu, on a large chunk of hardware.

Google's decisions in Android structure feel asinine.

I think it's not so much as the vendors of the graphics card and such that only released closed blobs to go with the open drivers in the kernel. And while they may work with say, ChromeOS, getting them to work on Linux isn't as straightforward. Android has a similar issue, though most of the time people aren't jumping from Android to another OS..

Dunno. I guess you could look through the project site and see if they have more details.

https://www.chromium.org/chromium-os