Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I help people make things using the Android OS - things that are not phones and that do not include the Google ecosystem. I have also been involved with using code from AOSP to create Android compatibility for non-Android OSs and in convincing OEMs of non-Android system to use it. In my experience I have traced the boundaries of what Google allows people in general to do, and their OEM partners to do with Android.

This is roughly how it goes: If you want to use AOSP for anything, including competing with Google, go for it. Google won't sue you, and won't even FUD you the way Sun did and Oracle continues to do if you want to use an open source Java implementation.

If you make Android devices that use Google's logo and proprietary code and ecosystem, you can stuff Android full of crapware that your carrier partners want, and that your product managers delude themselves into thinking gives you "differentiation," even though Google really does not want that to happen. What you can't do is compete with Google, or take a cafeteria approach to using Google's apps and ecosystem. You are in or out. No in-between.

AOSP is Apache licensed and Google adheres to the letter and spirit of that license. Both B&N and Amazon compete with Google using AOSP code and there has never been a hint of FUD aimed at them for doing so.

Many China-market phones with China-based ecosystems are based on Android. Here is where the lines blur a bit: China-based Lenovo gets away with making AOSP-based products for the China market with non-Google ecosystems and they make Google-logo Android phones. Somewhat famously, Taiwan-based ASUS was slapped down by Google for trying to do, as far as I can tell, exactly the same thing. There are also Google OEMs who make OPhone handsets. So Google hasn't been 100% consistent regarding OEMs with one foot in the mainland China market and one foot in the Google ecosystem.

It also appears that OEMs licensing other OSs, notablely Windows Phone, get no retaliation from Google.

I also dealt with Sun, trying to get a license to use Java in a VoIP-oriented OS. They were utterly opaque bastards about the licensing process, cost, etc. and about their position regarding Java patents and open source implementations. to the point where we concluded they could go to hell and we would use an open source Java implementation. Using AOSP is by contrast FUD-free.



It wasn't ASUS that got slapped down, it was Acer. ASUS, Samsung, Huawei (and probably others beyond Lenovo) have had no trouble distributing AOSP-based products without Google services. Acer's situation was different for two reasons:

1. Aliyun (Acer's partner in this) was distributed pirated apps via their app store, including pirated Google apps: http://www.androidpolice.com/2012/09/15/aliyun-app-store-con...

2. Google claimed that the Android-based OS that Acer and Aliyun had built did not pass the standard Android compatibility tests, in violation of Acer's agreements with the Open Handset Alliance (a prerequisite for their license for the various Google apps). I'm not sure if a third-party verified this claim before the project was killed, but it's plausible. And we do know that most of the non-Google products OHA members distribute in China should pass those same tests. They're usually the same as products the member is selling outside China with Google services, with the exception of China-specific radios.


Yeah I was wondering if I got the two confused. You are correct, it was Acer. The other points you bring up are also correct. But there is more:

If Aliyun does not pass CTS, it's good enough to run those stolen apps. Also, as I pointed out, other OEMs get away with having both Google logo phones and Aliyun phones. (Aliyun was the Alibaba OS, and has been "spun out" though it's hard to tell if that is a meaningful separation.)

Aliyun is certainly not the only app store selling apps that were never submitted by the developer for distribution. It's a commonplace form of sleaze.


> If Aliyun does not pass CTS, it's good enough to run those stolen apps.

I don't think we know that. Just because APKs were listed in a store doesn't mean they did anything useful when installed. I don't recall any evidence one way or the other about how well the various pirated apps actually ran on an Aliyun device. If you know of any, I'd appreciate a pointer.

Separately, I agree that Aliyun's sleaze is relatively common, but so what? I'm not suggesting Google should (or even can) proactively police every app store out there. I'm just saying Google is well within their rights to come down hard on one of their partners working with a store that pirates Google apps, wherever it happens to be. Honestly, I'm still puzzled about why Google leaned so much on compatibility in their response. I'd have thought that the issues with unauthorized distribution of Google apps were simpler and more clear-cut.


I have seen Aliyun handsets. Like other China-market AOSP-derived systems, Aliyun is Android without Google's ecosystem. It will run any Android app up to the API level used in Aluyun you put on it. The claim that it's not CTS compliant is, at best, splitting hairs. No specific incompatibility has ever been claimed, and no set of apps have been shown to fail.

Google is free to allow or deny anyone access to their proprietary app suite for Google-logo Android handsets whether they are consistent or arbitrary about it. I'm merely pointing out that that some OEMs, like Huawei and Haier, get away with building both Google-logo Android handsets AND Aliyun handsets, while others do not.

Like many Linux-based products in China, there are other things that are wrong with Aliyun in addition to dubious app market practices. It doesn't observe open source licenses, for one thing. But Aliyun being "bad" isn't the point.

I am just pointing out that Google is usually, but not always, consistent about enforcing a policy that Android OEMs can't participate in AOSP-based products that compete with the Google ecosystem. In some cases the OEM relationship appears to be more important than a consistent policy, or perhaps licensing regulations differ in the PRC.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: