PSA: Chrome for Android

[Marcus Bulach]

As you probably have seen, today we launched Chrome on Android!
http://googleblog.blogspot.com/2012/02/introducing-chrome-for-android.html

We’re all very excited with this launch, and whilst this is a milestone for our project, it’s just the beginning our long journey together.

What happens next?
Chrome on Android is currently a fork of the chromium code. Unforking and upstreaming this code is one of our top priorities, and the majority of our team will focus on this. Note that we have a lot of code already upstreamed, such as the OpenSSL port for the net module (yes, that was for android... :), a lot of the GPU effort has been done upstream too, we shared some parts with TOUCH_UI, etc.

Exciting! What are the major challenges?
There are many interesting challenges ahead. One of the most interesting ones is that in Android, the system API (C/C++ on gtk / windows, Objective-c for cocoa / mac) requires Java, and to call to / from C/C++ we use JNI. More details soon.

We’ll follow standard chromium practices, and in general we’ll send out RFCs for fundamental design questions to chromium-dev, and for less controversial bits, we’ll send patches to the corresponding OWNERS directly.

What about infrastructure, try-bots, buildbots, commit queue, etc..?
We’re actively working on it! We’re hoping to send out PSAs, as the infrastructure evolves quickly to support the Android port.
We do have a lot of infrastructure (clang, perf, lots of tests) downstream and we’re planning to upstream and integrate. We also have some bots upstream, such as the Android WebKit, which we have committed to actively maintain. In order to get to that stage, we also have cleaned up the previous android port of webkit (see this post https://lists.webkit.org/pipermail/webkit-dev/2011-August/017738.html).

What about docs?
We’re also actively working on them! We’ll be adding them to http://www.chromium.org/developers as appropriate.

What does this mean for my feature X, or my platform Y?
Hopefully we’ll have no additional overhead or any negative impact. :)
Android will be a first-class platform like the existing ones. Please, keep an eye for further announcements, specially with regards to new infrastructure coming to the waterfall. Feel free to reach us on #chromium irc channel or email us if you have any specific questions.

How can I help?
Thanks for volunteering! We’ll need a lot of keen eyes to review our patches during this upstream effort, and of course, the usual guidance and help from the chromium community. Please, let us know if you want to help.

On behalf of the Chrome for Android team,

Marcus Bulach

Satish Sampath

Andrei Popescu

John Grabowski

Peter Beverloo

(you can reach us in the irc or from this email..)

[Pierre-Antoine LaFayette]

I'd like to volunteer. 

p.s. I like the more polished version of my edge swipe tab transitions Android Browser feature in Chrome for Android: https://www.codeaurora.org/gitweb/quic/la/?p=platform/packages/apps/Browser.git;a=commit;h=9d41dd87506313444124d55f92057ed4831a8dbb 

I should have patented it ;)

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

--
Pierre.

[shen yi]

Two questions for Android chrome browser:

1) Are the UI components like 'address bar', 'bookmark view', 'windows view' are written in Java?

2) For stock android browser, it is using WebView to render the web content. For chrome, what is used for rendering the web content ?

Thank you!

Yi

[PhistucK]

1. Java is used for the native user interface, yes.

2. The Blink rendering engine, of course.

And I am not sure the stock browser uses WebView, it makes sense to me that it uses (well, used) WebKit directly, but I do not really know enough.

☆PhistucK

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Bo Liu]

Stock android browser uses webvew: http://developer.android.com/reference/android/webkit/WebView.html. Webview was using a fork of webkit before kitkat, and now using chromium+blink stack in kitkat and onwards.

[PhistucK]

​I meant that I do not think it uses the WebView API, but its underlying WebKit ​library itself. But, again, I do not really know.

☆PhistucK

[Alexandre Elias]

The stock Android browser did use the WebView API, not directly the underlying WebKit library.  This was viable for it because the release cycle was in sync, so they could add new WebView APIs whenever Android browser needed one.  For Chrome, since it's unbundled and on a much more frequent release schedule, as well as having an existing very dense content "API" layer that has many fundamental differences compared to WebView (for example a lot of asynchronicity) that isn't workable and we package Blink directly in our .so.

--
Alex