Hacker News Reader

Comment by JBReefer | Hacker News Reader

On one hand, this is a truly incredible accomplishment for Google, and in so little time! On the other, it's sort of amazing this hadn't happened already - so, so many people in the developing world are entirely reliant on mobile, and mostly use low-end Android phones.

I use a Moto G4 and the experience is shockingly good for a device that costs less than a bar tab. It's no wonder that low-end Android's are winning, based on my experience with it. It's not the same caliber of phone as a new iPhone or a Pixel, but the difference is not worth $800.

And all of this is mostly open source, runs on Linux using Java, and can be developed on for free. This seems like a good timeline! (even if the API isn't that great)

View on HN

Don't forget that the proprietary Google Play Services are required by more and more apps and that Google is doing everything it can to push these services to the largest number of devices by weaving some sort of web of interdependency.

I agree it isn't perfect, but services that phone home to google servers can't realistically be open source. Google is pushing them insofar as it is trying to make them better.

I think it's still a far cry from the state of affairs on iOS or MacOS, and the fact that you can fork it if you are willing to replicate those apis is still reassuring.

> I agree it isn't perfect, but services that phone home to google servers can't realistically be open source.

Yes, they can. Google makes a conscious choice not to make them open source. There's no fundamental law or anything saying that they can't.

I think the better question is: Why do those services need to phone home? There are plenty of apps that should work just fine without doing that, but don't.

Why does location services need to phone home? Or the App Store? Or push notifications? I think most of these are obvious. I am not aware of any non-obvious ones, but if so they are more likely for crash reporting or usage metrics than for advertising.

Obviously some of them need to phone home, I'm talking about the ones that don't need to. And, just because it can't phone home doesn't mean it should stop working altogether.

Yes, and you have to swallow the whole blob as soon as you need any single one of the services. Just want "cloud" messaging for your app? Force anyone who uses your app to install the whole blob. Want just assisted GPS? Too bad, you still force anyone who uses your app to install the whole blob.

If Google had made the services modular, it would probably be easier to replace them with homegrown ones, but they made it a blob because that gives them more power. There are efforts to replace this blob with other manufacturers' blobs (like the one Yandex is working on, or microG) but it looks like this is not easy and it's not going quickly.

We also probably get a typical reverse-engineering situation where Google's services will always be several steps ahead of anything anyone else can offer as a drop-in replacement, so the alternative looks less and less enticing to the average consumer and they'll probably go with the blob :(

   but they made it a blob because that gives them more power

They made it a blob because they need the data to generate revenue. Googles services are free, if you let them have your data. I'm 100% certain that a paid alternative would not survive because people does not want to pay a reasonable fee for the services, when they can have it for free if they let Google save some, to the User, harmless data - they even get personalized content in return.

you can include just one component of the entire Play Service library (e.g. cloud messaging) in an Android Studio project with a line like this in build.gradle:

  compile 'com.google.android.gms:play-services-gcm:10.0.1'

but, i get the impression that's not quite what you mean when you say "install the whole blob."

i guess you're talking about the Google Play Services library, which is updated independently of my app. or something like that.

https://play.google.com/store/apps/details?id=com.google.and...

not quite sure. trying to clarify this for my own understanding.

AOSP may be open, but on its own it is a skeleton of a OS.

Most of the magic in Android today is housed in Play Services, one of two things Google can push an update for (the other being the Play store app) without any dialog or concent from the device user.

I'd say the majority of end users are not particularly knowledgeable about Google Play Services and the Store app to make an informed decision on whether to accept or not an update.

I think I agree... and that is a huge problem! The same can be said about Windows Update. Or any computing topic in particular! Which is an even bigger problem.

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.

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.

Or the device maker and network provider, both were the bottlenecks in pushing out updates.

> one of two things Google can push an update for [...] without any dialog or concent

One of the two things Google _chooses_ to do this for. Nothing prevents them from doing the same thing for other pieces of software, except, perhaps, their own policy.

What I'm most excited for based on my time in Liberia, is when these mobile first citizens wring all the juice out of mobile devices and are able to adopts tablets and then computers. The things they'll be able to do since their grew up on these tiny devices will be incredible.

"the experience is shockingly good for a device that costs less than a bar tab"

Glad to see someone else lives it up at the bar

See you at the Bungalow

It's not so surprising when you consider that those people in developing worlds visit way fewer pages than someone on a broadband connection on a computer would - in part because it's still a smartphone with a small screen (especially the low-budget ones), it's slow, but mainly because data is expensive.

Agree entirely! However, Google still has a lot of work to do to put some sort of order in the lower end of Android devices like reducing fragmentation, offering a more unified experience for users and making sure that new devices are not shipped with obsolete hardware and software. Android One, for example, is a great initiative that desperately needs to go global.

Reply on news.ycombinator.com