Who will steal Android from Google?
medium.com
medium.com
So any company who wants to exclude Google puts their entire mobile product line at risk on this play. It'd be hard to see anything coming of this unless multiple manufacturers can agree to make the jump together, creating a platform large enough that even Google has to support it for their own market share needs (which means, this group must include Samsung, who's hedged their bets on this sort of thing but seems too scared to make the jump). And even then, this only remains an option as long as the Pixel remains niche. If the Pixel gains an iPhone-like market share amongst the broader range of Android devices, Google can mostly tell other manufacturers to screw off.
His notions on cross-platform frameworks making a non-Android platform viable are spot on though. Not only through things like React Native, but PWAs, which Google is pretty bullish on itself, despite the fact that it may make Windows Mobile a viable idea again.
iPhone is generally behind the curve when it comes to hardware specs, but nobody cares about that because iOS is such a strong platform.
It's not always true, but it's a good rule of thumb.
Java's bytecode execution speed in the JVM is good enough that it's on part with C, easily beating any language with even a slightly inefficient compiler, like Go or Haskell.
class A {
B b;
}
As long as the market share of any newcomer is low enough, Google can leave them out in the cold for app support (or intentionally interfere by blocking YouTube access, similar to what they did with Windows Mobile, and now Amazon's Echo and Fire platforms), and they'll die off for that reason alone.
Whether it's an Android fork or a new OS like Tizen or some new Windows flavor, it won't beat Google unless it has the market share to force Google to support it with apps. And it's hard to get that market share without Google's support.
Nice spin there! Youtube was blocked on Windows Mobile because Microsoft blatantly blocked all the ads in violation of policy. If Microsoft was in the right here, we would have seen a lot more aggressive posturing from them instead of silent retreat.
And for Amazon, it was a reaction to Amazon's decision not to sell Chromecast (and Nest devices). Amazon's excuse is that Google changed Chromecast APIs, which smells weak when you see other supported apps on Chromecast from Netflix, HBO, ESPN etc.
The Amazon/Google spat goes back a lot further than that, which I've talked about a bit in other comments here.
Here is a link to an overly-well-sourced comment I wrote on this:
Why would anyone expect Google to handle Microsoft with kid-gloves in this bout of corporate-combat when Microsoft was playing to win? You don't bring a knife to a gunfight.
I don't know if Windows Mobile was ever faster or smoother, but for certain it was not in the last few years.
In fact, I had a phone with Microsoft's Android Bridge beta, and while people were complaining how slow the Android apps were on it... I realized that it was more or less just the normal performance Android apps ran at.
Seems a little disingenuous to pin performance against a half-implemented ASOP API running on an environment without all of the JVM bytecode tuning Google has put into ART/Dalvik.
I assume it was related to the inefficiency of the Windows kernel compared to Linux.
http://blog.zorinaq.com/i-contribute-to-the-windows-kernel-w... "I Contribute to the Windows Kernel. We Are Slower Than Other ...
I have never seen an 150 € Android devices that were as fast as they are.
They killed the Microsoft YouTube client because it didn't play by the rules regarding showing ads or downloading videos.
And in terms of other hardware (RAM, camera, sensors) I would still say it's arguable
Really? In all the benchmarks I've seen, the latest iPhones handily beat the latest Android phones. (And old iPhones remain usable longer than old Android phones.)
Assuming the software doesn't get in the way, benchmarks are all about hardware, not software.
No, if the OS significantly slows down a benchmark, it's a bad OS. Both Android and iOS are fine in this respect. (It's a bit fuzzier for graphics tests, I admit, where driver quality comes into play.)
From what I understand iOS is pretty picky about background processes. Limit what can run in the background (and for how long) with android and you will probably get similar results.
A quick google search gives me results like this: https://www.tomsguide.com/us/galaxy-s9-benchmarks,review-519... "Galaxy S9 Is Fastest Android Ever, But iPhone X Is Faster"
With the exception of China Inc. No place for Google so far.
That being said, while a Chinese manufacturer could try to branch out into the international market, that hasn't been working out for them so far. Huawei and Xiaomi have both pushed in that direction, but beyond limited success to begin with, now government entities are discouraging Chinese brands due to perceived cybersecurity risks. Whether those risks are overblown or not, it has severely hampered these companies' ability to branch out to the international consumer.
https://www.npd.com/wps/portal/npd/us/blog/2018/with-homepod...
day one pre-orders of HomePod were higher than all other
smart speaker first day pre-orders, except Amazon’s Echo DotI don't know what Android tablet would be in next place after the Kindle. If you count big phones with styluses, probably the Galaxy Note. I know the Samsung Galaxy Tab line exists but I've literally never seen one.
Google has a weird relationship with consumer devices. They release stuff, then seemingly completely abandon it for years. I don't know what exactly their goal is with some of these devices, but if e.g. Microsoft did the same thing with the XBox, they would never be where they are now.
I always assumed google's hardware stuff was basically a reference implementation. When traditional manufacturers 'get it' google steps aside.
I always get the impression that Google doesn't want to be in the consumer hardware market, they want to be making software and online services supporting consumer hardware. They participate in the hardware market to drive the market in the direction they want it to go, but really want third-party hardware partners to do the heavy lifting on consumer hardware.
> I don't know what exactly their goal is with some of these devices, but if e.g. Microsoft did the same thing with the XBox, they would never be where they are now.
Their goal seems to be to become what Microsoft was with the PC market, only in more markets and with a bit more active hand in steering the hardware markets.
It's not just with devices. The most obvious place this happens is with IM services. Whether it's intentional or not, maintenance of existing products seems to be frowned upon within Google since promotions are mainly based on releasing new products.
Yup. It was the right size (can fit in a pant or suit pocket!), it did everything one could want, and it worked just fine. Of course Google killed it.
What? Kindle Fire initially did really well, and Amazon was briefly no. 1 in Android-ish tablets and no. 2 in tablets behind Apple, but they’ve lost marketshare and others (mostly Samsung) have gained, largely on the back of the official flavor, rather than AOSP-derived versions like Amazon's, of Android.
> Tablets are either iPads, Surfaces, or Kindles now.
This would be closer to true (and in order of sales from most to least) if you said “Galaxy” in place of Surface.
> I don't know what Android tablet would be in next place after the Kindle.
Samsung sells more, in total;Amazon may have the highest selling individual model of tablet powered by an Android or Android-derived OS, but they don't sell the most devices.
> I know the Samsung Galaxy Tab line exists but I've literally never seen one.
I've literally never seen a Kindle Fire, and I saw three Galaxy tablets before I left my house this morning. But that's just anecdote, the more relevant thing is marketshare reports, and while different reports have the figures differently (and often breaks out only by vendor and not OS, and makers like Samsung have more than one tablet OS since convertibles are usually counted), but consistently across reports Amazon is significantly behind Samsung in tablets, e.g.:
https://techcrunch.com/2018/02/06/apple-continues-to-dominan...
Looking at that IDC report, you'll note that Samsung is at -6.4% year over year for 2017. Amazon is at +30.0%.
If you look just at Q4, Amazon was in second place behind Apple (with Samsung in third), at +50.3% year over year compared to Samsung's -13.0%.
Those numbers do not indicate to me that Samsung is doing well in Android tablets. Granted the Samsung tablets are much more expensive than a Kindle Fire, so you'd expect it to be low, but the year over year downward trend is not impressive.
https://www.idc.com/getdoc.jsp?containerId=prUS43549518
EDIT - also note that the Galaxy Tab S3 (I think this is the current version?) is still shipping Android 7. Apparently Android 8 support is in development, but "it's going to be a while."
https://www.sammobile.com/news/galaxy-s7-galaxy-a5-galaxy-ta...
Bummer about Google's official tablets, they were better about software updates. The Pixel C (released at the end of 2015) got android 8 but will not get 9. Still, that was pretty good by Android standards.
Re: Surfaces, I'm probably overestimating these because I see them in professional use. They're pretty expensive to get much consumer traction.
I ended up buying one of these: https://www.simbans.com/tangotab.html. So far it's OK.
Most of the things that sell Amazon Fire are its really cheap price (it is probably a loss leader), seamless Amazon's Kindle and Content integrations (such as Prime as well as FreeTime). However, there are no Google Apps on it - no maps, no gmail, no Youtube etc. It is a really hamstrung experience if you have used their product.
Android is much much bigger than Amazon tablet and to say Amazon is eating away at Android is a disingenuous statement.
Granted Amazon is big but Android tablet marketshare as a whole (exclusing Amazon) is much bigger. I would use data to back your assertions vs. what I am observing (as that is subject to echo chamber and confirmation bias risks).
That is very country specific, I hardly see any Kindle that isn't a plain e-book reader around here.
What I see on my train travels is people using iPads or Windows 10 tablets with detachable keyboards.
Anecdote data, take it as you wish.
Higher up-front cost than a cheap fork of Android, for sure... But how much? Especially if they could manage to make a native development ecosystem that was plausibly competitive to Apple’s, but allowing for easily targeting Apple’s devices as well, I could see this strategy being a better way to stave off competition from third and fourth players.
There’s prior art on cloning Apple / NeXT APIs and whatnot. Surely a company with the heaft of Amazon could do at least as well as the small open source efforts.
And sure, the 'getting started' examples of every new framework or platform that promises to fix the warts of the previous one look compelling - but then you start building actual applications, and people find out they need to add this and that and by the time it matures we're 5 years on; and it has accumulated just as much (different, but just as much) cruft as the ones before it.
And if the Java layer is already a mess, with the documentation scattered all over the web instead of Android docs, those of us that adventure in NDK could use a quote from Dante.
React Native is really good, but I wounder how many developers will be able to move from OOP or Web development to Declarative Programming.
I think we'll continue to see a lot of Kotlin and Swift developers for the next decade, as both languages are still attracting many new developers. Android and iOS have been playing nicely with the compatibility layer, but could potential break it if they begin to lose control of the market place. Developing in React Native, while having lower costs, is still more risky than having two native development teams.
I was writing some dotnet core 2.0 code the other day and was shocked to find it was missing an officially supported odbc as well as many of the System.Data classes that use to be a big workhorse for developers. .NET has serious problems.
Microsoft invested in other technologies that were obviously doomed from an outsider's perspective for far longer than they should. Windows phone and Bing being the two biggest and most obvious stubborn failures.
A lot of companies now compete with Google in one or several markets, and being forced to include Google Search would be fairly painful for a lot of them, so Bing tends to be an immediate contender for anyone who isn't Google trying to integrate search capabilities. Obviously, a fair segment of their market share is just "Bing is default on Edge/IE, and Edge/IE is default on Windows" as well.
https://en.wikipedia.org/wiki/Web_search_engine#Market_share
Microsoft almost certainly spends a lot less money on Bing than Google spends on Google Search, there's a good chance that Microsoft's spending per search query is lower than Google's. Bear in mind, being "good enough" costs significantly less than being "the best".
Also, Microsoft announced that Bing started being profitable in 2015, and they've grown since: http://www.zdnet.com/article/microsofts-bing-search-business...
No flashy things but a lot of boiled goose.
Even then, a solid cross-platform dev platform like React Native is actually a boon for Android which is second fiddle to Apple when it comes to premium apps. Right now, anyone looking to reach profitability will go iOS first, then web, then Android. Making the cost of bridging the gap to Android smaller will only increase adoption.
Despite my opinions regarding native UIs, the fact is that we are yet to get pure native apps contracts, they are either Cordova/Xamarin/Qt or plain web based.
The majority of enterprise shops do not care about native UI/UX.
I find the concept of "native look and feel" to be extremely nebulous and not particularly valuable. Apps should look good and be responsive and I don't notice or care when they look native.
Thanks for your Xamarin feedback.
But from a business standpoint, it's a huge risk. If Google wants to get OEMs to switch from an established, widely popular platform to a new one, they're going to need one heck of a big carrot. It's likely Google would retain more control with Fuchsia, since giving OEMs control of experience, security, and updates is largely responsible for many of Android's woes, and OEMs will be resistant to that.
Google may have a much easier time retaining it's control under Android than trying to push a platform switch, which could actually, lead to OEMs switching to a different company's platform instead.
If it becomes possible to update to new Android features and security patches without breaking OEM overware, then OEMs no longer have to dedicate teams to rewriting their crap codebases.
Which means they can put all those developers on features instead.
Which is what they've always been interested in and (arguably) better at in the first place.
Some Chromebooks can now run Android apps; I wonder how that works out for the user in practice. (I haven't tried myself.)
Also, considering Chrome OS has an Android layer in there why wouldn't fuchsia be able to do the same thing? It should be more than enough as a temporary solution.
They're both open source, so I wouldn't be surprised if someone built an Android server for Fuchsia though.
1) Pixels move to Fuchsia, native apps are in Dart/Flutter, compatibility layer for Android. Fuchsia becomes a distinguishing feature of Googles hardware, and allows Google to differentiate vs Android competitors.
2) Google continues to support Android, but only as it affects their business interests (as a funnel for search).
3) Google migrates some service level functionality away from Android and Pixels become a first-class citizen in Google's ecosystem.
In my mind, Fuchsia is a direct result of Google's newfound interest in hardware (as a business). I imagine the following:
- Google sees voice (and maybe AR) as the next frontier, which is actually an existential threat for them--they are harder to monetize via ads.
- Google decides to start making hardware (for profit), to monetize their services (a la Apple). That is, their Voice Assistant is now differentiated from Android, and to use that service, you have to buy their hardware. Now, they don't need to make money on ads for voice searches.
- Google will continue to roll out more ML-driven services that are exclusive to their hardware, and eventually, exclusive to Fuchsia. This will allow them to both a) further differentiate their hardware from other Android manufacturers, b) better monetize their services (effectively through HW purchases), and c) steal market share of the most valuable customers from Apple.
Fuschia won't replace Android or Chrome OS. It will just be the third OS product they make.
I agree with your point that Google's history has been to take a multifurcated (and sometimes conflicted) approach.
I might immediately click out of it, but the barrier for me to click is lower initially.
I ran a wordpress blog for a while. What a godawful piece of shit that is. Security critical updates all the time, and HAHAHAHA, they regularly break themes. I have no idea why, but probably because wordpress refuses to create a nice them api so they can try and gpl every theme. Plus it's slow. Plus it's difficult to secure. I had originally used a hosted wp instance until that got repeatedly hacked. Then I ran it myself. Yuck.
Then I used octopress for a while. I had to configure nginx and ssl and then deal with things like figuring out why pygments broke. Something went wrong with python which obviously I'm using inside by ruby blog engine. Mathjax deprecated their cdn and I'm still too lazy to go fix it.
Medium, imo, creates a nice solution where (1) writing is pleasant, (2) publishing is easy and comes out nicely formatted, and (3) when you're busy, you spend the majority of your time writing instead of doing ancillary things.
It sounds like you didn't know how to secure your server with at least chroot jail, selective port filtering, and njinx injection filtering or apache fail2ban.
I have been running multiple wordpress sites for years and have never had issues. These sites have custom themes I wrote to take advantage of the wp_ apis, to do much more than just blogging.
For example: http://gregoryscoffee.com is done entirely as a custom wordpress theme. The different coffees are actually posts in the Coffees category - their thumbnail is fetched by grabbing the image attachment on each of the posts. In fact, all the dynamic content is stored as posts. The owner has no problem updating the site, since it is all editable in the normal wordpress admin.
This discussion is about blogging, so IMO it's a valid comparison. While WP can be used for a whole bunch of other stuff, that doesn't change the fact that it's one of the most popular blogging platforms.
> It sounds like you didn't know how to secure your server with at least chroot jail, selective port filtering, and njinx injection filtering or apache fail2ban.
Well, I shouldn't need to know those things if all I really care about is blogging.
Being backed by Google should also aid it in API compatibility vs other cross platform frameworks who are always playing catchup with the native API's.
Static types, hot reloading, a solid library of widgets, native performance, "reactive" just like React.. seems like a win to me.
Regarding the points made in this post on front page today [0], I think Dart being an unsexy even "boring" language is a good thing, since it's so much like other languages new devs won't wast time with a steep learning curve.
From an evolutionary perspective this can help the platform catch on quickly.
I think if you want to make a lot of relatively small projects, web dev might be easier for a while. But as your projects start to scale up in size, having proper inheritance, compilation, a type system, etc. has growing benefits.
Don't forget, among the companies that are sinking money into replacing Android is also Google. They're preparing for a fight.
Times when OS's were fundamentally replaced because of industry paradigm shifts:
- Unix -> Linux
- MS-DOS -> Windows
- Windows 3.x -> Windows NT
- ProDOS -> GUI ProDOSs
- Android with a Blackberry clickwheel interface -> Android with a touchscreen
- Windows CE -> every other mobile platform
- Mac OS -> OS X
- OS/2 -> Windows NT
- CP/M -> MS-DOS
and so on.
However, if iOS apps do come to the next version of MacOS, we might be on the verge of delineating Mac OS X and MacOS into truly-separate generations.
On the Mac culture, UNIX is only an implementation detail, most users don't care one second it is there.
Not even Mac developers, those that actually target Mac users, not using it as a workaround to avoid dealing with Linux/BSD issues on laptops.
Microsoft screwed up on numerous occasions with Windows. Once the monopoly was in place, that simply didn't matter so much. Consumer behavior reinforces the monopoly even in the case of screwing up: people very aggressively stick with what they know. The same will be true of Google-Android.
Getting consumers to switch is extremely difficult. Competing with Android is extremely expensive. Delivering your Android killer at exactly the right time, with a vast improvement over Android, with the right marketing hit, with the right partners, with the right hardware - good luck, it's not going to happen.
If I as a company was forced to give 30% of my revenue to Google (or apple or ms), you'd best be assured that the most important thing, long term, is to make sure I get 100% of my sales. That is a very important carrot that you can use to get developers to switch - and as you alluded to, its just one piece of the puzzle.
Igave it a try to a "small" project and there weren't any noticeable advantage over Gradle (and given that Instant Run is working quite well, it was really buggy when it comes out).
I know for a fact that aside from Facebook, Uber uses it and comes out with a nice Gradle plugin for Buck called OkBuck[0]. I wonder what other big shops use as well. And I would like to know if anyone here has used it and saw any dramatic advantage over Gradle and worth investing time integrating Buck into current projects.
The fact that iOS is successful without a comparable build system (everything is bound to Xcode projects and tooling based on that undocumented changing format), makes me think he's overestimating importance of the build system.
Meanwhile, Uber (their marquee Gradle customer) just switched to Buck -- I don't think Google even knows this yet.
The build system in Android is a huge pain point for the dev stack. It's a big part of why things like React Native are gaining traction.
Your comparison to iOS is basically invalid/irrelevant, because iOS doesn't have the same legacy packaging issues (APK) as Android has. Android's build is actually quite complicated, more so due to the device proliferation, and it's getting worse over time.
Hope that helps. I'd be happy to answer more detailed questions about why it's so bad, since I've worked on it extensively in the past.
Sure, this is why it's adopting a structure similar to Blaze, Buck and others with smaller modules, not to mention sharded compilation with Instant Run. The whole reason for Blaze, Buck, etc. existence is that common build systems fail at huge applications used at Google / FB / Microsoft scale. And yet that doesn't seem to stop adoption of build systems like Maven, SBT, Gradle and all others which are used by vast majority of developers not working at GooAmaBookSoft scale.
> Meanwhile, Uber (their marquee Gradle customer) just switched to Buck -- I don't think Google even knows this yet.
Tools team is certanly aware of it.
> The build system in Android is a huge pain point for the dev stack. It's a big part of why things like React Native are gaining traction.
Not sure how second follows from the first. React Native is gaining traction because it lets developers quickly develop for two platforms at once (just like Xamarin, Cordova, Ionic gained a lot of traction in enterprise before). Instant redeploy is very nice but hardly a huge deciding factor.
> Your comparison to iOS is basically invalid/irrelevant, because iOS doesn't have the same legacy packaging issues (APK) as Android has. Android's build is actually quite complicated, more so due to the device proliferation, and it's getting worse over time.
Huh, lack of proper build system is a huge headache when doing iOS CI builds. The compiler is also comparably slow for Swift/ObjC (especially if you add just a bit of C++ code) so I don't know how can you just dismiss it. It has very similar issues and the adoption didn't suffer.
> Hope that helps. I'd be happy to answer more detailed questions about why it's so bad, since I've worked on it extensively in the past.
Not sure what you worked on (I'm guessing Gradle itself?) but it doesn't seem like you know all that much about building Android apps with Gradle in most companies out there.
I think you're wrong on this one. A large number of devs care about dev experience at the expense of other important things like platform maturity, reliability, and security.
I don't agree with many of Steve's points in his post, but I do agree on this point. Both factors - x-platform development and instant redeploy - have contributed significantly to React Native's success so far. Indeed, if it weren't so important, I wouldn't expect Google to invest as much time and money as it did in getting Instant Run to work correctly (like others said, it was buggy as all hell when it first landed in Studio's stable channel and only became usable after many months). The fact that Flutter advertises "stateful hot reloading" prominently is just more evidence that it's important for attracting devs.
True. Gradle (and its Apache Groovy build DSL) conquered a market by first creating that market. There's really no need for a build system with a procedural build language -- a declarative language to describe a build like with Make and Ant/Maven is good enough.
so, they addressed that pain point by using Gradle, which also did dependency management really well (compared to say Ant and, many would argue, Maven) and by incorporating/integrating the Gradle Android plugin with the intelliJ IDE.
Instead someone at Googleplex managed to steer a team to rebuild the world to their favourite IDE and in the process reboot the whole Android development stack, which by the way is still not done.
Oh, and the NDK support was in limbo until Jetbrains released CLion. Had CLion not been released and to this day there wouldn't be a solution how to use the NDK inside Studio.
I bet Google IO 2018 will again have a talk about how to improve Android build speeds.
Indexing that one cannot turn off unless laptop mode is enabled, spinning the HDD all the time, really?
Also none of our customers IT teams allows InteliJ on their leased hardware/VMs to external partners.
The exception being Android Studio.
I don't know, Gradle allowing easy extensions allowed us to do continious delivery significantly easier than with Maven (not to mention iOS build system). It's not a must, but it's a really nice thing to have when you need to build several versions of a build, tag versions dynamically, build docs, etc.
> It’s like everyone who’s ever tried to do Android programming gave up and declared: “This is so bad that I will do my own startup to make it better.”
> And Google, not to be outdone by their competitors, responded by saying, “Oh yeah? Well you can’t compete with us, because we’re going to compete with us!” and they launched Flutter, which is — I am not making this up — a 100% serious Android development stack that competes with native Android, and whose existence the actual Android team simply refuses to acknowledge.
This is incorrect. Every one of these I've heard of (all the big ones) and probably the rest don't exist because Android development is so terrible, they exist mostly to facilitate one codebase for both iOS and Android, or to allow the use of a different language.
I mean, that's incredibly obvious, so I don't know why he's got this here.
Compiling AOSP today will result in something that look and behave not much different from late 2.x Android.
Any examples?.As a developer, the one's I think of are location apis (still available in the AOSP, but requires much more code to get right than the google play services version). And the look and feel does not depend on the play services sdk.
In Android 8.0, AOSP does not include any of these anymore.
In Android 8.0, you need to use Google Play services to get Location, Stepcounter, any device sensor, recent TLS on pre-8.0 devices, any of the above apps, background job scheduling (the new JobScheduler only works on 8.0 or Google Play services), and so on.
I've written apps that don't rely on Play Services, I had to reverse engineer and clone half of Play Services to even get a semi-working version.
Nowadays, the source code of a new Android version is released months after the binaries are released, and over half a year before the first binary beta releases are released (Android P's first beta binaries are out today, the source code is expected in december).
You can already build apps for Android P, making use of the new features - if Google gives you the required code, which they only provide to themselves and a selected few developers.
Google makes it as hard as possible to compete fairly, and this has already caught the attention of the EU.
And then, of course, there's the fact that the Chromecast SDK requires Play Services (so you can't use Chromecast on Kindle devices), and that receiving Chromecasts is even entirely impossible at the current time for non-Google devices (these are the reasons why Amazon doesn't support Chromecast, but is instead together with Netflix trying to establish a cross-platform API that can use Amazon's sticks, Miracast devices, Chromecast, and many other devices).
Google has done everything they could to be as anticompetitive as possible, and of course this will lead to legal action. Potentially half of the Android ecosystem at this point may be based on criminally anticompetitive actions.
You can only commit the crime of "abusing a dominant market position" if you have a dominant market position.
- Anticompetition law applies to monopolies. While Google has several products or services with over 80% market share, Apple has none. Apple's highest share of iOS is in the U.S., where it rolls around 50% with Android, but globally, they barely make an appearance on the board. EU's anticompetition law has no interest in a phone platform with less than 15% of the market.
- Apple tends to make a lot of things proprietary, but they're also only used by them in the first place. iOS only runs on iPhones. Google gets into a lot of additional trouble by exerting it's control over it's OEM "partners". For instance, bundling it's Google Apps together as a requirement for OEMs is definitely illegal, whereas Apple putting it's own apps on it's own devices is not.
You're a monopoly if you have a almost complete hold of the entire market, which Apple does not, for any market they are in.
They did get into trouble regarding price fixing of ebooks, for example.
That sounds a lot like distributing binaries of copyleft software without distributing the corresponding source. Of course, I'm sure there's a very good explanation of how it isn't that, because that would contravene the copyright licences and be all illegal and stuff.
A major part of the Android ecosystem is based on unspoken piracy of the Linux kernel.
actually, it works on Android 5.0, thats the version it was introduced in.
-> In Android 8.0, you need to use Google Play services to get Location, Stepcounter, any device sensor, You don't necessarily have to go through play services for any of these. API's are available in the platform for all of them or can be replicated.
I think the possible anti competitive behaviour from Google(in Android's case) is forcing the OEM's to install their apps by default.and practically forcing developers to use Play services for notifications.
All the sensors are only available to foreground apps, and only while they are running (at significant battery cost).
The only way to get aggregate data is through Google Fit or other Google APIs. I've tried.
> actually, it works on Android 5.0, thats the version it was introduced in.
There's three versions, but all either require modern Android versions, or Play Services. I detailed this on reddit recently.
I agree. This point is under appreciated. The GPS libraries and their backend services (e.g. Maps and Location, Push Notifications, Google Auth, etc) to a great extent ARE the android SDK.
I don't quite see how Yegge's use of the word "stealing" can be correct. No one can steal those backend services. A competitor is going to have to reimplement services like Maps and Push Notifications (not to mention the Google Play Store itself). And that just means more fragmentation in the marketplace, not stealing android.
Recently by the open microG project, and earlier by Amazon.
Reimplementing every Google Play service, bug for bug, bit for bit.
And Amazon did it (and microG is close).
This is what prompted Google's SafetyNet project, and Google changing Chromecast to lock out Amazon and open source projects.
Google did everything they could to prevent competition, and yet, they didn't succeed.
Any AOSP app that has a Google app equivalent generally stopped being updated when that Google app equivalent was released. The AOSP music player was last updated for Gingerbread (replaced by Google Play Music), Gallery was replaced by Google Photos, the SMS app by "Google Messenger", the Mail app by "Gmail" -- even the Phone app is no longer updated!
There are many examples, but some that come to mind are Google letting Google Voice near-die via insufficient maintenance/investment. Or Google literally giving away the opportunity they had in capturing chat (via Google Chat) due to a confusing strategy (Google Chat/Hangouts/Duo/Allo/app-of-the-day)
If you look at these toolkits in that light then their existence is justified without it being a nail in Android's coffin, so to speak. Not that the underlying tooling can't be better, but devs are moving towards cross-platform toolkits precisely because they are cross-platform, not because Android is terrible.
1) the WeChat scenario. Amazon is probably the best positioned so far and their platform and services are also available on iOS and Web. The potential WeChat could avoid the Google tax by handling payment, but would likely have to offer many of the Google Play Services (notably voice recognition, maps, and location) so Google would likely still be involved (also e.g., GV invests in Lyft and Uber).
2) Future OS includes Android compatibility. Another platform that can also run Android (and therefore has Google Play) apps isn't really a loss for Google, but it is a way for Android to be commoditized in favor of another. Steve is betting on Amazon, but Samsung is probably the most successful with their store (which doesn't seem very successful). If anything Google itself has the advantage here - they mostly have it working on ChromeOS and I'm willing to bet Android compatibility with come to Fuchsia.
When he says Microsoft has the best tools for React Native, does he mean something like ReactXP [0]? Or Does he just mean Visual Studio Code?
(i.e. can i build the builder itself from source code ?!)
I'm looking forward to receiving my Librem 5, and I'm pleased Lineage continues producing phone software intended for users, not advertisers.
Android the OS is pretty safe, as cyanogen.com valiant run at Google from this angle proves out.
Which means other vendors can far more easily keep all their apps and move to a non-Google controlled mobile OS of their own.
The thing is that with Google Play Services libraries and the Google Play Store, Google has a really strong lock on a huge collection of apps out there.
Using something like ReactNative on top of that stuff kind of seems like a baby step away from Google, but there's still so much Google control to eliminate.
It's analogous to how the browser came along and turned the desktop OS into plumbing for a lot of people. My wife uses a Mac but she really has no idea that it's a Mac. She only uses the browser, so she could easily switch to Windows. Apple has really no hooks into her at this point, and that's an uncomfortable position for Apple (or any desktop manufacturer) to be in.
Google _needs_ to maintain control of the developer experience. In my opinion they should add a TypeScript option to Flutter, embed the v8 javascript engine into Android, and support Flutter with JavaScript as a first-class citizen on the Android stack. They should start this work yesterday.
My favorite quotations:
1. "Android’s dev stack is the world’s biggest poo sandwich"
2. "And Android? Yep. It’s the biggest poo sandwich of them all."
3. "...there are two Android APIs for getting mouse-click events on a scrolling list, but one of those APIs doesn’t work on LG. I mean come on."
4. "I love Kotlin; it’s the future of Java. But let’s face it: It’s not where the mobile market is headed. "
5. ... the Android org at Google is not sure whether cross-platform is good for them or bad for them, but that they are leaning towards “bad”
6. "most of the big shops are aggressively dumping [the android gradle build system] in favor of Buck — Facebook’s Android build system. Google is chasing a dying strategy here."
7. "guess who else is making a big play with a competing [android app] store? You guessed it: Jeff Bezos"
8. "if you’re locked in a fierce competitive race ... and need to launch faster, you should probably go with something other than Android Native ... Among the cross-platform options, React Native is looking like a winner"
9. "there are a lot of big sharks circling the Android boat. Google needs to be careful."