Hacker News Reader

Comment by rtkwe | Hacker News Reader

That's kind of a demon of necessity though. Originally they did things more in the base OS but getting manufacturers to actually push updates was horrible. Now they can do bug, (minor) security and feature updates through a side channel that bypasses the carriers who don't want to update their older phones when people might go buy new ones instead.

View on HN

Thing is though that is proprietary to Google, anyone wanting to use AOSP for their own has to clone the APIs.

This makes a lie of the whole notion that Android is open source. Yes, the skeleton is open, but the guts are proprietary. And the skeleton on its own is useless.

What makes it useless?

Look at the efforts that Amazon continues to invest in Fire, and CyanogenMod (the Company that Went Bankrupt as opposed to the jailbreak mod that still mostly exists) tried to invest in a Play Store/Play Services competitor, and Samsung is trying to invest in its efforts while also trying to be stealthy about it in its current Cold War with Google...

Android (AOSP) forks are numerous, yet competing with Play Store/Play Services seems expensive and onerous. Nontechnical consumers don't see Amazon's Fire as Android, just an Android-like system that runs many Android apps. Nontechnical consumers thought the same about CyanogenMod (the Company)'s efforts. Samsung's Cold War seems so desperate, from the outside, because they are trying to walk that fine line between remaining a consumer Android and yet still distance themselves from Google's control.

AOSP forks seem alive and well in China.

But yes, in rest of the world non-Google Android is struggling.

I'm curious how many of the Chinese forks label themselves as "Android" and if the Chinese have a different mental model of what "Android" means.

Without any first hand knowledge, I'd assume that the balance of things towards WeChat and away from Play Store/Play Services in China might mean that "Android" really does mean something different in Chinese markets? It's easier to sell an "Android" device if the benchmark is "runs WeChat" rather than "runs the apps I see advertised everywhere" (given the near ubiquity of Play Store emblems on American ads) and "runs the collection of apps I've bought over the last few years from the Play Store".

I am Chinese and I've been living in the U.S. for a couple of years, so I know both worlds. Everyone I know in China who use an Android has ton of apps on their phones. I'd say there are at the very least tens to hundreds of thousands of apps to choose from either in the various third party app stores or directly from first party websites, and it's very common for people to have multiple apps with similar functions, e.g., four or five web browsers.

I don't know where you learned about the misinformation that is "the balance of things towards WeChat and away from Play Store/Play Services in China", which is frankly quite ridiculous because WeChat is just a messenger app with a few added functionalities (social timeline, payment, etc.) — it's not comparable to an app store or a service SDK at all.

Thanks for some perspective. I'm sure my curious bias about WeChat stems from how often it dominates chat bot conversations (esp. here on HN) and how often chat bot conversations mention WeChat as if it were the largest Chinese app store/service SDK. Fresh perspectives help tamp some of that enthusiasm.

Back to my original curiosity, outside of my supposition you think is clearly wrong, do you have an impression that Chinese phones that have forked AOSP and don't have access to the Play Store/Play Services still count as "Android" in China? If so, can you give an indication why that might be different than in America where Play Store/Play Services are nearly synonymous with Android?

There's no technical necessity for it to be closed source, though. That's a business decision.

I imagine the bits that to talk to Google's servers need to be.

I imagine that's a purely business decision since Google owns the code and can open-source it if they wish. There's no reason that the code to talk to Google's servers needs to be closed source.

One reason is API change. For closed source solution they do not have to worry about API changes but open Android has to have much more elaborate API deprecation and change process.

That isn't true.

Nothing about open source requires that they in any way stabilize their web-side APIs, the process they would follow could be the same as their binary releases, just with open source code released at the same time.

In theory that's true, but in practice, not so much. Even if they told people to not use those APIs, that they're not stable, people would still use them, based on the open source they saw. And then they would change, and people would be mad.

This is assuming that Google wants people to see and be able to use these APIs in the first place.

And the people who would read the code to see the APIs' use aren't capable of doing the same with a network monitor?

I understand the concern, but I'm not sure I believe it's really that significant.

This is incorrect for multiple reasons. The two big ones off the top of my head:

1. They could release source and provide no guarantee of supporting API backwards-compatibility, exactly as they do today, only with the source available publicly.

2. They already deal with API deprecation. Owning the client doesn't get it to every device instantly. Even logic pushed into Google Play Services requires a (sometimes lengthy) rollout and relies on customers to approve the install.

To be clear, the discussion isn't about whether Google should pull things out of AOSP and put them into Play Services. The discussion is about whether Google can open the source for those components. So long as Google owns the copyright, the answer is a clear yes.

Well, for one they got manufacturers to adopt Google branding for Android phones, but then we're led to believe that getting them to update on time was hard. But from Google's POV, the only "necessity" here is that Google gets your data and tracks you.

> but then we're led to believe that getting them to update on time was hard

"Led to believe"? Is there any dispute about the fact that most Android manufacturers deliver major updates very slowly and often not at all?

So apparently "phone manufacturer must preload all Google applications" and "phone manufacturer must set Google as default search engine", and "Google network service must be preloaded" made it in the contract, but "phone manufacturer must update the phone" didn't. Those sneaky phone manufacturers !!

Those things you listen actually make less work for the manufacturers, and speedy updates make more work - that solves the mystery for me at least.

Oh, its not a mystery at all. Its just odd to come across people (in general, not you) who still think an advertising company would care all that much about their users (who are not their customers anyway). But yes, they're quite far from being the worst in this aspect.

Well I'm guilty of that same conception too. Why are the two at odds? Google wants to own the best platform for users out there. Engineers want to work on the best, app developers want to work on the best, and users want to use the best they can afford.

They can care for selfish reasons. If android is completely riddled with bugs and is constantly compromised users will use a different phone system. Even outside security issues being able to roll out new features to people keep them from switching to iOS or Windows Phones.

Clearly lack of updates is not meaningfully hindering Android's success.

Maybe "fast updates" is a standard clause in the contracts and device manufacturers are simply doing a bad job and Google doesn't want to piss off all its partners by litigating this.

Reply on news.ycombinator.com