Google's philosophy about AOSP apps

[Jonathan Marsaud]

Hi,

Just a quick question: what is the philosophy of Google for AOSP apps, since they have their own proprietary variants?
I read a comment of Dianne Hackborne which said that Google tries to push everything that's not related to their proprietary services & backends to AOSP, but it does not seem to be the case for all AOSP apps:

For positive aspect (*when* it seems to deal with what Dianne said (code not tied to Google's Services and so, backported to AOSP from proprietary version):

- Dialer vs. Google Dialer -> OK, the only lacking function is tied to Google Services. Moreover, in the Android L Preview Dialer is updated with "Material UI".
- AOSP Calendar vs. Google Calendar -> OK, the only missing feature seems to be the "all synchronized notification devices", I think it's using the Google Cloud Messaging services so it's proprietary.
- Camera vs. Google Camera -> OK, missing Photosphere feature, but Photosphere relied on Internet servers of Google (personal deduction... I have some strange results when I try Photosphere without an Internet connection).
- Launcher3 vs. Google Experience Launcher -> Pretty OK, but no: no Google Now or CallerID informations, but that's related to Google contents (so, OK), but lacks of transparency in AOSP Launcher3 (so, not OK)

For the negative aspect (*when* this AOSP apps seems (not officially) not maintained or a feature that does not relied (as far as I can tell) on Google's Services)

- Keyboard vs. Google Keyboard -> KO, lack of the Swipe Feature. At least the AOSP Keyboard use the Material UI in the Android L Developer Preview.
- SMS/MMS vs. Hangsout -> KO, No real updates (features, UI update) to SMS/MMS since Hangout becomes the default SMS/MMS senders in Nexus ranges.
- Search vs. Google Search -> KO, Search has an UI frozen to FroYo guidelines.
- Music Player vs. Google Play Music -> DEFINITELY KO, I think it's the worst case... Music has a very old UI and is buggy on high-DPI devices. No new integration to the lockscreen.

Not-so-sure aspect:

- Gallery vs. Google+ Photos : Google+ Photos has replaced AOSP Gallery in Nexus ranges, as Google+ Photos permits sync to Google+ and is not based "on top of the AOSP Gallery", I think it will be not maintained. Can you confirm this?
- Browser vs. Chrome : It's a special case. 1) Chromium for Android does not really exists as the desktop variant, as Chromium for Android is just the released opensources for the testshell and the new Chromium WebView of Android API's. 2) AOSP Browser was updated (as far as I know) to use Chromium engine instead of WebKit. In Android L Preview, AOSP Browser use Chromium 35.0 if I look at his UserAgent string. Can we consider AOSP Browser as the open part of Google Chrome? (Not related to this mailing-list but, do you know if Chromium for Android is planned?)

First thing, I love Google Services, even if I am an OSS enthusiast, but I understand that Google needs proprietary clients to their backend servers of proprietary services, no doubt in that.
I just want to know what parts of AOSP is really maintained (even if all the part that I mentioned on this mail is officially always supported by AOSP) and with what philosophy of "backporting functionality" Google goes.

My point of view about this subject is that it seems Android was in the first versions *entirely* based on AOSP, with some proprietary clients to Google proprietary services, and that was quite cool. You can compile AOSP, runs it on your phone (with some proprietary drivers, yes) or in an emulator and said "I have a full turn-key OS that does his main job (abstract hardware for software) and comes with maintained first party core apps!".
Now, it seems that if I compile AOSP, I always have a real opensource OS, but for at least the half of core-apps, I need to find some third-party replacement to have an updated apps.

On the other hand, it's about "Do It Yourself" of OSS : YES! But as contributions for AOSP is validated by Google Employees, if they don't want to maintain an AOSP apps, why they would bother with my patch? It is their rights. I always open an issue to revamp AOSP Music under the Apache licence, and no answer for the moment.

To resume: What is the philosophy/politic of Google about AOSP apps? When they reverse non-Google features to AOSP?

I do not know if it's the right place for this subject (and if Googlers read this groups :-)), if it's not, can you inform me where can I forward this message to have an answer?

Regards,

[Jonathan Marsaud]

I forgot the Email client but the answer was given by Google's in a previous subject on this group: "The email app is not intended to be removed from aosp, we intend to push the latest source publicly soon. We have been focused on the Play Store release, the next task for us is also." -- Martin Hibdon

[ch...@christopherprice.net]

So, I obviously don't speak for Google, but I think these questions are far too wordy to get an official commentary. Most of them are management-related and not a simple yes/no that warrants a direct answer.

As to the browser, AOSP Browser is not part of Chrome. There's a major difference between Chrome and Chromium.

At one point, AOSP Browser (previously WebKit) and Chrome (built atop Chromium) were distinct forks. Today, AOSP Browser is based on Chromium for Android, as is Chrome for Android. But, AOSP Browser is not Chrome. What separates Chrome from Chromium is equally present in Android and AOSP Browser. Also, a few Chromium features have been deactivated in the AOSP Browser build, such as Incognito.

Google Experience/GMS users do have the option of a closed-source SSO plugin that will sign them into Google web services automatically.

You can also turn features like Incognito back on, but you have to bake your own AOSP build to do so, as you're modifying Chromium files in /system - though root users can do a hack that overlays an alternative AOSP Browser.

In all, I think Google is walking a good, albeit fine line. We can't innovate and disrupt in computing using Android, without a common AOSP to build atop... let alone raise the funding to do so with gusto, and become good contributors (which is what my team intends to do).

AOSP remains open, and if someone wants to take the time to improve Music - they can do so. Clearly Google has developed some alternatives that work better - but are dependent on Google services, and thus shouldn't be in AOSP in the first place. I think the onus is on the community, not Google to improve the AOSP core apps in that case.

On my team, we committed to sharing AOSP code once we're mature enough to have the resources to assist in getting changes committed. We're not there yet, but we're well on our way. I don't see the moral hazard if Google doesn't accept a commit or decides to do so - offering them up is just the right thing to do, and makes our life easier too.

The only area I would see Google needing to step in, is if a CTS/CDD-necessary app becomes so old that it no longer builds cleanly, and yet Google still keeps it as part of CTS/CDD as a hard requirement. That, AFAIK, hasn't happened yet to any AOSP component for which a Google equivalent exists. One could argue Music breaks on hi-dpi devices, but I don't see this as a CDD-breaker.

The vast majority of Google Experience/AOSP shared apps build atop AOSP equivalents rather than replace them, and Google improves upon them as (what appear to be) Gradle build forks. Keyboard, Calendar, Gmail (and now Email), etc. That's A Good Thing™ for Android and A Good Thing™ for Google too.

In a thread I just submitted (not yet live), I do ask some similar, clear-cut yes/no questions that I feel need to be answered at this point, but are outside the scope of this thread.

Christopher Price

ConsoleOS.com

[Jonathan Marsaud]

Note: The only exception seems to be about Chrome. vs. AOSP Browser.

Jonathan Marsaud

Le 30 juin 2014 19:42, "Jonathan Marsaud" <jonatha...@gmail.com> a écrit :

I do not think Google will accept patch for AOSP Music improvement, as it means that after a contribution, Google needs to maintain this new code lines. And as Play Music is not based atop AOSP Music, they will need to maintain two music player.

My general deduction is:

1) If an AOSP app can be better with Google Services integration, Google dit it on top of the AOSP apps and release the openpart wich is not tied to their services to the corresponding AOSP app.

2) If a Google variant is a totally diverged apps or represent a Google Service itself, it's full closed source without any AOSP backports.

If I have understand correctly the situation, it's kind and fair from Google, in my opinion.

Jonathan Marsaud

--

---
You received this message because you are subscribed to a topic in the Google Groups "Android Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-contrib/c1kr8Pwfzhg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-contr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jonathan Marsaud]

I do not think Google will accept patch for AOSP Music improvement, as it means that after a contribution, Google needs to maintain this new code lines. And as Play Music is not based atop AOSP Music, they will need to maintain two music player.

My general deduction is:

1) If an AOSP app can be better with Google Services integration, Google dit it on top of the AOSP apps and release the openpart wich is not tied to their services to the corresponding AOSP app.

2) If a Google variant is a totally diverged apps or represent a Google Service itself, it's full closed source without any AOSP backports.

If I have understand correctly the situation, it's kind and fair from Google, in my opinion.

Jonathan Marsaud

Le 30 juin 2014 15:24, <ch...@christopherprice.net> a écrit :

--

[ch...@christopherprice.net]

I think your first/main assertion is incorrect. AOSP routinely accepts code for things that Google doesn't bundle on GPe/GMS devices.

If you have a fix, for example, to AOSP Music, submit it. You might have to get the attention of maintainers and make a case for your commit, but that largely depends on what the commit does.

Personally, I think Music doesn't get updates, because the Android community has made great alternatives. From DoubleTwist on the native side, to Spotify on the cloud side... and even direct rivals like Amazon MP3. Music even has pure OSS rivals like Vanilla Music.

AOSP Music doesn't get attention because it doesn't need attention... not because AOSP maintainers have some unwillingness to accept commits for it.

Christopher Price

ConsoleOS.com

[Jonathan Marsaud]

Anyway, I have no complaints about Google's strategy about AOSP apps vs. Google apps. They drop us a *cool and amazing* OSS platform, and great proprietary services (as they always did, so it's not my point).

I just want to know if Android is changing from a "full-turn key opensource software" (=core-apps are opensource) + proprietary Google's related apps to their online services on top of that (like Android 1.X/2.X was).
Or "a barebone opensource OS" + whatever you want, from a Google Experience, OEM Experience or a third-party experience you choose. Sound like Google is doing his own Touchwiz/Sense.

The two options does not upset me, Google did a great job and while the "barebone OS" is OSS, I'm completely pleased, I am just curious as a developer and an Android enthusiast.

Regards,

[Jonathan Marsaud]

Note that the "full-turn key opensource" solution (OS + core-apps) does not mean core-apps are not replaceable by third-party.
It's just about "what's out from the box, by default".

--
Jonathan Marsaud
GNU/Linux The dynamic duo