Samsung could have bought Android first
phonearena.com
phonearena.com
So yeah, they made the right move knowing their strength and weakness.
It's related to the concept of Power Distance by Geert Hofstede (http://geert-hofstede.com/dimensions.html), but it's not exactly that. Denmark, where I am from, has extremely low power distance (even lower than the US: http://geert-hofstede.com/denmark.html) which means your seniors will treat you like and equal but in a polite sort of way. There isn't the sense of you-might-be-in-my-shoes-tomorrow or at least that's how it feels to me.
One job I had, I was hired by the owner of a multi-million dollar a year company at his kitchen table with his wife and their kids were making a racket upstairs playing. He was always approachable and a friendly guy. One of the best jobs I ever had.
Years later he sold the company to some venture capitalist outfit out of Boston (I think it was Boston) that had hopes of expanding the business he created. Everybody at the top of that thing acted as if they were more special than anyone else in the room (including some high level people) not realizing they were just that somewhat interesting white speck on top of chicken shit.
Once it became clear there was no interest in continuing the successful path of the previous owner, I left. Something like 75% of my department (including some high level people) thought the same and left as well. I put in my notice to my boss a day after he had put in his notice. That was a fun final two weeks.
In Europe, we had Nokia Communicator smartphones since 1996. They had web browsers, and you could install apps. They never took the market by storm like the iPhone, but they were smartphones allright.
Thankfully, when news started coming in that NTT DoCoMo was making tons of cash off of data streaming and text messaging, then the carriers were all in.
I really hate this `Apple invented smartphone' nonsense; it reeks of `The Party had invented helicopter, aeroplanes -- and gradually eveything else' straight from Orwell's 1984. Are we /really/ that gullible?
[1] building on P900 (2003) and P800 (2002), which were pretty smart on their own.
Historical revisionism is a wonderful thing, apparently. Reviewing where Android was when it launched, a good few years after these events, and you can only conclude Samsung were 100% right. Android had a slow VM (far slower than the others already in the market) very high system requirements, and represented a whole new incompatible ecosystem.
Much of the world had moved on to J2ME's MIDP 2.0, with Japan and the US the notable exceptions with i-mode and Qualcomm's C based Brew platform respectively. As later happened with Android the fragmentation problems of J2ME were greatly exaggerated by a whole mini industry of companies reliant on the illusion. J2ME certainly had problems, but if you were delivering more than 100 different builds (I'm aware of groups pushing 1000) then you were completely and absolutely insane. It might sound like creating 100 different builds would be a big problem, but the differences were really fairly trivial, and not much worse than Android today which primarily benefits from most of the OS having been written by one group, except for the driver layers, whereas previously a lot more was on the OEM.
I'm a fairly loud proponent of the merits of Android, but what is even more widely ignored is that J2ME was in many ways superior to it, most obviously in the way it handled application permissions. For those that have dug into the platform it's amazingly clear that without the iPhone coming along and spurring Google on to greater things Android would have been a complete non-event at launch, especially with the dire performance of the early devices. The concern for Android developers today is that now Google have done just enough to edge out the iPhone in the market (though not in terms of developer experience, thanks to the giant incoherent mess of an API) they're leaving the platform to stagnate. Perversely the best thing for Android devs right now would be if Apple or MS produce an absolutely killer version of their respective OS's forcing Google to invest where it's needed to stay in contention.
So I certainly wouldn't rate Samsung as a software outfit, they're notably terrible, but Google have caught many of the old MS diseases, especially when it comes to doing only enough to destroy competitors and then leaving it hanging. If you compare the iOS and Android APIs you can't escape the conclusion that the iOS team have pride in their work, and the Android team are constantly having to make excuses for what a rush they were in. Both groups drove the other to greater heights, but the impact both eventually had in the market is only thanks to the other having driven them to get there.
Data storage
The SQLite API is a mess (you end up with SQL polluting a frightening amount of code once you start using it), along with associated content providers and the way this stuff attaches to views. This is particularly noticeable around the MediaStore, which is one of the truly horrendously fragmented areas of the system. If I had more faith in the future of the platform this is what I'd attack first as the potential for improvement for developers and end users is immense.
UI framework
The very core of the layout algorithm (where it traverses the views for information) is about as wrong as it can be while still appearing to function. Using styling or animations results in a horrifying explosion of xml files edited by the slowest xml editor in existence. They need a decent MVC UI system (the Cocoa killer feature), not this hacked together mess. Whoever came up with Fragments does deserve a medal though.
General API cleanup
The API has inconsistent naming and code style throughout. A lot of it is clearly the work of people more comfortable in C or C++ writing Java for the first time, but there are packages where NIH syndrome seems to have occurred between different groups of the Android core team. One of the NS* API features is even thoughTheNamesAreSoLongJavaCantCompete at least they understand the benefit of consistency, whereas in Android every package feels unique. J2ME was superior to Android in this respect, and the people designing it also knew when to use primitives and when to use objects. Android uses too many objects for things like touch events, resulting in far too big a load on the eternally inadequate garbage collector.
Permissions
They need to actually launch the feature whereby you can install an app but deny it permission for particular operations. I suspect once they proxy ad stuff through Play Services they'll try to switch this on, as if they did it right now 90% of the noise would be ad supported app devs complaining users are disabling their network connections.
Finally, relatedly, the documentation is horrific. It's quite common to find references in examples to methods that don't exist (and the examples written in yet another bizarre coding style), or magic details are referred to but not demonstrated or explained. I have got more useful info by reading the source for the system itself. If you go and read the source for a project like DashClock any reasonable developer goes and cries in a corner. That's PHP4 style development, not the way you preserve sanity over a long period of time.
At least the storage and UI could be added in a compatibility library, so the fragmentation argument wouldn't apply. Kitkat has added superficial improvements for some areas, but again it's just enough to allow users to not notice the gaps with iOS, while leaving many Android devs spending a disproportionate amount of time adding stupid hacks to paper over the inadequacies of the platform.
I didn't use the SQLite API, but isn't the point of that API to "pollute" your code with SQL? I might be misunderstanding your complaint here-- do you believe the API shouldn't exist at all? Or that it's overused? It seems like there are a few cases where SQL is exactly what you need-- like building a finance program or something.
With regard to the UI: I always saw the Layout classes as the View, the Activity as the Controller, and the Model as the classes that implemented the application itself. If anything, the big complaint people had seemed to be that Android was too structured, that it required you to do too much work before seeing anything on the screen. I agree that the XML files often seemed clunky, but at least you could vertically center a text box without magic, something that's apparently very difficult and unintuitive with HTML. Android also planned ahead for different screen sizes and form factors. The real "hack" (in the bad sense) is what Apple had to do when they made the iPad-- to run iPhone apps with doubled, blocky pixels to preserve the aspect ratio.
Speaking of the "eternally inadequate GC", Android's GC has gotten better over time. MUCH better. I remember back in the 1.0 days 100 ms pauses were common. Now, the average is less than a tenth of that. The UI is still not as responsive as iOS, but it's getting there. I see no reason why the GC couldn't improve even more, with top people at Google working on it.
With regard to the permissions thing: I agree with you here. It would really be nice to give users the ability to deny certain permissions to apps. As you mention, they probably don't do this because they don't want to destroy the business model of ad-supported apps that use the network. Hopefully some kind of solution can be reached here.
I never actually developed for J2ME, but I knew a few folks who did, and they hated it. I remember tales of being stuck with Java circa 1.4 (no generics), ancient libraries, and even... ugh... Swing. I'm not that familiar with J2ME, so again, maybe it improved later on? Also, do you really think that delivering "100 different builds" (your words) is an easy thing for a company to do? With Android, I only need to deliver one build, and I have a store that can do most of the work for me. I think you are looking at the past through some seriously rose-tinted glasses.
While it is not clear that Android under Samsung would have become big (likely not), it would have been an effective blocking move for Samsung, delaying and possibly thwarting Google's dominance in the smartphone market. Samsung had an opportunity to control Android (and possibly kill it). Instead, Android went to Google who built it into a major powerhouse... and now (a) Samsung is heavily dependent on that powerhouse and (b) has very little control over that powerhouse.
1: Let's skip the discussion as to whether Android is actually free and open source and instead remember how much more open Android is compared to what was before.
We see this kind of article every now and then and they do not bring anything but couldas/shouldas/wouldas.
Some of the software written behind closed doors on Sony hardware in around 2006 looked a lot like a modern games console UI. The problem was the US was largely an incompatible market (brew) so you had to pay for this stuff just with Europe, so it remained a niche.
The modern mobile industry view of history is hilariously US centric, when until 2007 it was one of the moat backwards markets around.
It's not clear if Android was offered to Samsung as a base for a shared platform (it's often mentioned that this is the fundamental reason for Android existing, but people seem to assume Samsung wanted their own OS, and the Android folk may have been desperate enough for cash to go that way) but if so it wouldn't have been a particularly crazy idea.
And even Samsung's Bada shared elements of Linux and HTML5 platforms, so it's not a total silo.
If Samsung had acquired Android, none of us today would own an Android smartphone.
Had Samsung bought Android it would have been a footnote in history. If I had to guess we'd be looking at a 90s-Microsoft-like dominance of smartphones by Apple.