New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 113088 link

Starred by 454 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Owner: ----
Closed: Nov 2013
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Feature

Sign in to add a comment

Let Chrome be used by WebView

Reported by, Feb 7 2012

Issue description

Phonegap and other similar frameworks use WebView to embed HTML/CSS/JS, enabling developers to create Android apps utilizing modern web technologies. The Android Webkit browser is less capable and buggier than Chrome however, which leads to difficulties for developers trying to make apps using that technique. 

It would be great if WebView could opt to use the Chrome browser instead (where supported), so that developers could use the more modern browser.

Showing comments 9 - 108 of 108 Older
Yes, this is the main reason I'm considering going native. Fighting android is probably costing us 50% of the project budgets.

Comment 10 by, Nov 20 2012

This would make app developers so happy. Chrome for Android is so nice, and the default browser is so horrible. Please please, please, please, please let us embed Chrome in an app.
Yes, I'll say it again PLEEEEAASSSE
Webview for android is the Internet Explorer of the mobile world.  Please make this right.

Comment 13 by Deleted ...@, Dec 7 2012

This would be such a huge improvement for the platform, I really hope this is prioritized
Hey everybody, if you just want to voice your support for this can you please star the issue and *not comment*.  if you leave a useless comment, it gets emailed to all ~160 of us who have starred the issue and gets our hopes up for seeing some official word on this.

(i know, i'm being part of the problem.  sorry to everybody this is being emailed to)
Fantastic idea. A bit hard to implement but fantastic nonetheless. 

Comment 16 by Deleted ...@, Dec 7 2012

Here's a novel idea: if you don't care about user experience (and obviously you don't since you're using PhoneGap for development), just make your app a mobile web page and the user can elect to run it on Chrome, Firefox, Opera, or whatever other Android web browser they have.

Imo native Android apps are the way to go. I vote *against* this because I hate these WebView-based apps that just look like crappy iOS ports. I would rather have poor performance in WebView in favor of native look and feel Android apps.
Have fun implementing it natively on iOS, Android, Win 8 and so on. History repeats itself and native programming is like writing your own browser plugin as we did back in the 90ies. It has better performance, of course, but it's the poorer approach from the technical view.

Look the other way round: People are porting apps from iOS because the WebView runs smoother on iOS. If Android would be ahead of iOS - combined with the cheaper price and greater variety of devices - I would happily start with Android.

Just my 2 cents.
Greg, ever heard about 'hybrid' apps ? its native applications, but with some webviews included.

So you get the native UI feeling (navigation, widgets...) and you can include some HTML contents and get the flexibility of web technologies to do it.

Best of both worlds :)

For that purpose (and more) we need a Chrome WebView.

Don't forget that this problem doesnt really exists on iOS as the webview is already quite performant with a full Safari. So this is a real pain point for many developers.

Comment 19 by Deleted ...@, Dec 7 2012

I have written several native Android apps that make use of WebViews for display of HTML5 content. Most of them make use of Javascript callbacks to Android and zoom, pan, and scroll functionality.  

However, I don't think that every app should just be a WebView shell with all the functionality in HTML5. Seriously, that's what mobile web apps are for.  Basically, my complaint is that if Google makes a Chrome WebView, you'll have a very big hammer and every app will look like a nail.

Comment 20 by Deleted ...@, Dec 7 2012

I agree with Greg. We have a responsibility as commenters on this thread to make sure that hammers don't get into the wrong hands.  Keep development difficult. Poor performance ftw!

Neat! I didn't know Android web apps had access to the device's file system, camera, media (including recording audio) and more! 

Oh, wait... that's because they do not. 

A response of "just make a web app" is not really very helpful. 

+1 for the far wittier sarcasm of @PurpleCabbage
> Neat! I didn't know Android web apps had access to the device's file system, camera, media (including recording audio) and more! 
> Oh, wait... that's because they do not.
actually, they do:
A spec is not the same as support.

Comment 24 Deleted

currently supported by chrome, firefox, firefox beta, and opera on android.

currently supported by opera and firefox beta on android.
So let me see if I can sum your solution up.

If say you wanted to write an app that recorded audio and saved it as a file (chosen based on the two APIs discussed above), your solution is to write a web app that only works in Opera or Firefox Beta.

Yeah, I think the productive discussion left the building a while back.
no, my solution would be to write a native android app.
but if you insist on writing a web app instead, the apis do exist, and there are multiple browsers that support them.
This is not a forum, please keep comments relevant to the original issue.
As an app developer with a number of iPad apps, and now Windows 8 Metro apps, I'd like to strongly endorse this.  Chrome on Android renders our JS-intensive app extremely well, and the default Android browser is painfully slow (even on top of the line hardware).  If our app works smoothly on a Surface RT, it should be at least usable on a top-end Android tablet!  We've decided that we just can't release our app portfolio for Android until there's a Chrome-based WebView.

I don't understand this. I have a web app that depends heavily on touch events & CSS3 animations. On Android 4.1/4.2 the stock browser is way better than Chrome, which is very buggy when it comes to touch events & CSS3 animations. In the new Chrome beta it is worse than ever.

Apart for those bugs, I find performance (CSS3 animations framerate & JS performance) better in the stock browser. In fact, all the bugs I have found in Chrome are not in the stock browser. And of all the decent browsers I use for testing (both desktop & mobile), Chrome on Android is the only browser that is giving me problems. It would be a catastrophe for me if Chrome suddenly became the WebView renderer, especially the new beta.

I don't doubt that Chrome is better in some ways, but before setting it as the WebView renderer, bugs that are not present in the stock (current WebView) must be fixed, otherwise it would break working apps.
The android browser is functionally a dead end. It skips html5 features like indexeddb by design, and should be considered deprecated. 

While it makes sense to postpone the change in the near term, the switch is necessary and inevitable. I'd rather start developing on a new webview than a deprecated one.
Postpone? I'd rather see Android UIView be the default (at least for a while) and make Chrome an option asap, allowing for backwards compatibility while letting the rest of us move forward with a modern browser.
You're right, this makes the most sense. That way we can iron out the bugs before its default.

Comment 35 by, Feb 9 2013

> bugs that are not present in the stock (current WebView) must be fixed

@olejon88, if you know of Chrome for Android issues that don't already have bugs raised, please do report them via .  Particularly helpful if you can highlight where it differs to stock browser/WebView. Thanks.
@joth: Yes, I have filed several bug reports (e.g.  and . Looks like I am getting responses now, so that's good. What I don't like, is that new pretty basic bugs are introduced in the new stable (v 25) that are not there in the previous (v 18), e.g.  and .

I think having Chrome as an option for WebViews is a great idea. Two questions though:

1. Will the WebView renderer be updated together with Chrome from Google Play? If not, the WebView will always lag behind (like stock today).
2. What will happen with AOSP? I guess Chrome can't be included because of licensing issues. Will Google create a new browser interface or use the stock browser's interface with the Chromium engine? Lots of companies like Samsung and HTC uses the stock browser to make their modified versions (mostly UI changes).
Project Member

Comment 37 by, Mar 10 2013

Labels: -Area-Internals -Feature-OSIntegration Cr-Internals Cr-UI-OSIntegration
When is the Chrome option likely to be available as the WebView?
Seems that for Android 4 it is already. And for Android 2,3 there is no possibility to run Chrome at all.
Great, so how do we use this on Android 4?
I meant - Android 4 stock WebView is very similar to Chrome by perfomance and features, In fact it`s even better in some cases.
No, The Chromium engine is not used in WebViews in Android 4, and that is probably why it's faster. In my experience, Chrome still has a way to go when it comes to the overall performance of the Jelly Bean stock browser. Scrolling, zooming, panning, 3D CSS and JS animations, etc are still faster/smoother in the stock browser. In addition to that, the bugs  I have found in Chrome for Android are not present in the stock browser. Until that is fixed, Chromium should not be forced as the WebView default. Having it as an option would be great for those who want it, though.

The title is a bit misleading. It should say Chromium, not Chrome, as Chrome contains proprietary elements that can not be included in the open source project Android.

Comment 43 by, Apr 7 2013

In my experience, the Android stock browser is the slowest browser
around, in all aspects. Simply useless. I think that is what this
thread is all about.
On a Nexus 7, the old stock browser is faster and smoother than Chrome. But on Nexus 4, chrome is better ...

Chrome is a poor experience on Nexus 7, why is it laggy ?

Comment 45 by, Apr 7 2013

Here is a proof of concept of using Chromium code to build a view with the WebView API.

Please make sure to read the "Issues" section in the Readme before using this for anything serious. At the same time, I hope this inspires folks who have an interest in a Chromium-powered WebView.
Brilliant! Have you tried this on Android2? Will it work there? 

I expect that answers are "No", but let me dream a bit.

Comment 47 by, Apr 7 2013

Nice! Any idea of how much overhead using this chromium embedding adds to the app? And can you perhaps compile a lighter version of chromium if you need exactly which features you need?

Comment 48 by, Apr 7 2013

@dennis: I think Chromium only builds on Android 4+.

@i...: My debugging APK that includes both the ARM and the x86 .so files is 33Mb. An ARM-only APK is 17Mb, but this assumes you're willing to go through the hassle of publishing two APKs, or willing to ignore Atom tablets.
@per: And then I assume you are using a Google (i.e. a Nexus) device running the latest version of Jelly Bean? Other vendors like to f*** up the stock browser with their modifications.

Chrome 25 for Android actually beats the stock browser (just barely) in some tests regarding JS performance, but not all:

Though I don't really trust the Octane test since the Chromium devs seems to be optimizing Chrome for it (in my opinion the shouldn't optimize for specific tests):

Still, as a web developer I find the stock browser being faster in about every aspect on my Galaxy Nexus.

I have noticed Nexus 4 users being satisfied with Chrome's performance, but I see every day people preferring the stock browser, still. And yes, it is still there in Jelly Bean (AOSP), just not on some on the very latest devices from Google.
So I thought the entire point of intents was to allow an application to run a module available in another app if the user prefers.  So why is WebView not available as an intent and why does Chrome not also provide the same intent for their implementation.  Seems like the developers are not using the system as intended (pun intended as well).

Stock browser is crap.  The same web archive on the iPhone wipes the floor with even the most modern Android device.  The Android team should hang their heads in shame.

Comment 51 by, Apr 30 2013

@toddvlba: You can open a Web page using an intent, this bug isn't about that.

Comment 52 by, Aug 6 2013

I would very much like to see Chrome become the one and primary browser for Android.  Development and debugging would become much easier (I wouldn't have to resort to attempting to debug code on the Android browser) and results would be more predictable.  

Chrome has been and will continue to improve and is quickly becoming the preferred browser not only for Android but for iOS (albeit with a different engine).

Comment 53 by Deleted ...@, Aug 14 2013

Cannot wait for this... 
Any news or progress on this issue?

Comment 55 by, Aug 14 2013

FWIW, HTML-based gaming on the Ouya console is stalled primarily due to this issue.

For example, it's possible to use canvas but not WebGL.  Other features available in Chrome would also be extremely welcome.

Comment 56 by Deleted ...@, Aug 22 2013

I have developed a Cordova/PhoneGap application.  It works great on Windows Phone (which was my primary target) and iOS.  Sadly, Android's junky WebView was just way too slow.  I had assumed the miserable performance was due to the emulator, but once I released my application to the Google Play Store and tested it on a friend's phone, I was stunned.  The performance was awful.  I went home and pulled the application from the store before any other users installed it so that I could avoid the bad reviews.  For now, I have no plans to release an Android version because the WebView is so bad.

Comment 57 by, Aug 22 2013

Join the club. It is really to bad. We are telling clients to buy IPhones.
It that or port to java...
I just wanted to chime in and say, building your own ChromeView is possible.  A univ. grad student did it and threw it up on Github: -- it isn't perfect by any means, and there are some issues to work around, but if you *really* need this, and don't want to wait for Google to do the work, the code is out there, and it is possible.

If you compile the Android build of Chromium, it builds an Android app called ContentShell.apk -- if you launch this, you'll find it is a full-blown Chromium browser wrapped up in an Android app.  It is a good starting point for ambitious people who need to get this done.

I am working on doing this right now for an internal project, so I'm watching this space, but I'd be happy to share some notes if other people want to get involved.

Comment 59 by Deleted ...@, Aug 22 2013

The annoying part about this issue is that WebView is embedded into the OS and will only updated when the entire OS is updated. Even if Google decides to use a usable engine for WebView, you'll still have to keep supporting the buggy WebView for a while. 

Quoting this article:

"Q: Will WebView get updated?

A: WebView and Chrome browser will be the same when the OS is upgraded. Every 6 weeks Chrome will be updated but WebView will not. Just to be careful not to break anything."

The argument "Just to be careful not to break anything" intrigues me. Seems to me that the risk of breaking things is much smaller when releasing small bugfixes/improvements every 6 weeks instead of big updates on every OS update. It seems to me like an excuse for a wrong design choice.

From a technical point of view I get it: Native views definitely have their benefits and HTML is for the web, but not all clients have the budget to re-invent the wheel just for Android. 

Comment 60 by, Aug 22 2013

is very interesting,  would be good to hear about your trials and
tribulations with it.

Comment 61 by, Aug 22 2013

I tried Chromeview on the Ouya ( but ran into a problem with the Guava library (I think).  I'm not a Java Guy so if anyone does manage to make it work on the Ouya I would *really* appreciate hearing about it.

Comment 62 by, Aug 22 2013

With chronium having an Android 4.0+ requirement, even after they do create
a webview compatible interface to it one will not be able to use it as over
1/2 of Android users are using <4.0.

Also chronium will not be a panacea for all your woes. The same HTML5 site
that operates flawlessly on iPhone is still poor on Chrome for Android
(think animations). This is on the most recent Android phones available on
the market. It is hard to tell if this is due to chromium or hardware (GPU)
but as a developer it doesn't really matter. The end user experience is
what counts and chromium is not there (yet).

Comment 63 by, Aug 22 2013

@btoc: Indeed; however, the sooner this move is made, the sooner this de-fragmentation can begin and the sooner a single code base can be used to address these issues.  With only one browser under development, optimization and improvement should be much more efficient.
I'm not interested in supporting users on < 4.  People who have old phones don't generally buy new software.

I'm not feeling like Google really cares, and more and more I'm beginning not to as well.  I'm now supporting Windows phone (works great), ios (works great) and have an Android build (works just sort of OK mostly).  I'm probably going to abandon the platform if they don't get serious.

Android has new management in the person of Sundar Pichai.  Perhaps he will address this.  Anyone having personal contact chains to him is encouraged to contact him and make him aware of this issue.
@toddvbla: You can try to contact Sundar Pichai via Google+ or LinkedIn. 

Breaking WebView is just an excuse.

A solution would be to add a new class. WebChromeView. I wouldn't mind adding 20mb extra to my apk. 

I hope that Google can address this fast. 

How about they make the api accessible just like google play services.(I'm
not really that knowledgeable on android)
Like if the user has chrome installed on the phone it uses chromes api
instead, or an option to use it, or just like play services you could just
tell the user to install chrome to use the app.
I think what's probably holding this up is that there isn't really a "Chromium for Android", just Chrome and Chrome Beta. If there was a Chromium, that could easily take the place of the stock browser in AOSP and it would become the new default for WebView.

Comment 68 by, Aug 22 2013

@andrewrabon but there is a Chromium for Android.  Go check out the Chromium source (Android branch) and build it.  You'll get a native shared object that you can load into Android along with a .pak file (Chromium) needs, as well as Java wrapper classes around it, and a couple of Android apps that use it.  These Android apps are used by the Chromium team mainly for internal test purposes, but they are a great start to someone who wants to build their own ChromeWebView (which is what I am working on currently).

Like I said, the code is there -- it can be done.  It seems to not be a priority for Google, so I'm just pointing out that if you *really* want it, you can do it yourself, or hire someone to do it.

Comment 70 by Deleted ...@, Aug 22 2013

Chromeview looks promising, but too experimental at this time. And I want to support at least ICS. GeckoView also looks promising:

Nice thing about GeckoView is that Firefox will be using it as the widget for the browser.

A nicer solution would be raymond's idea (#66): Make sure the engine comes preinstalled with Android / is regularly updated.
GeckoView does look interesting.  ChromeView isn't ready for prime-time you are right.  It is an attempt at dissecting the complex Chromium build artifacts, and providing some Java glue to try to get close to the standard Android WebView interface.  

I have built Chromium and yanked it into ChromeView on my own fork of the project and I was able to create an Android app that uses it -- actually there's a simple demo app here that you can use to test with or modify: 

It works, but the AndroidWebView does have scrolling issues (I think these could be resolved, though).  So, the ContentShell.apk that is built as part of Chromium works flawlessly, so I am reverse engineering that, to figure out how to do my own ChromeView from scratch.  I don't really care about the full Android WebView interface, so I probably won't implement all of it.

The other nice thing is that the artifacts you need are the native shared object .so and the Chromium .pak file.  These can be placed in a central place somewhere in Android, so you wouldn't have to force users to package them with every app.  You could now revision the browser entirely outside of the standard AOSP -- want a new Chromium?  Just rebuild the shared object and update it on the apps that load the .so get a new browser.

My use case is different since the Android we're building on is a non-standard tablet / phone -- we're embedding Android ourselves, so we can control the internal libraries through our own update mechanisms -- similar to what Ouya is doing...we're building our own custom devices with AOSP.
I threw this up on github if anyone's interested: -- may be of interest

Comment 73 by, Aug 30 2013

Thanks! I'll try it on the Ouya this weekend. =D
@#72 Works really nice.

Trying to show 2 webpages(say tabs or contentviews) side-by-side. Is there a better way other than creating 2 ShellManagers in same activity? (or will that this even work?)
#74: This is really not the forum for that conversation.

Comment 76 by, Oct 24 2013

Hello please introduce this ASAP , webui for Android sucks , My team is developing html5 apps + phonegap ...while it just works on any IOS device , on Android it sucks big time , CSS transition is slow , hw acceleration makes it slower or has no eeefect and I am talking on top of line phones like s3 /note 2 

There may political difference between android and chrome team , I suggest for sake of developers please get together and get it done 

Comment 77 by, Oct 24 2013

chome is not the greatest.  you best bet is to support mixed mode rendering
and run as canvas on Android.  then use cocoonjs as your wrapper.

Comment 78 by, Oct 24 2013

please remember that ui webviews run 2-3 times slower than the same browser
outside your app.  even the newest chrome on an android 4.2 is still not
that good.  google is saturating the market with 4.2 devices and their
webviews are still pretty bad.  they still don't support

your best bet is to run in something other than the browser.  you need
something that goes straight to opengl.
Seriously Android Guys, the Android webview is very bad please change it.

Comment 80 by, Oct 24 2013

@gp: The only way to get smooth web animations on Android is to enable HW acceleration in the app and use CSS 3D-transitions, because they are GPU-accelerated, and really smooth, like native ones. Regular CSS animations and JS animations are laggy (especially with HW acceleration enabled in the app), and it doesn't matter if you use Chrome or the AOSP browser/WebView. Actually, I have had a lot more probems with Chrome + 3D transitions than with the AOSP browser/WebView (I have reported bugs), but they are mostly fixed now.
Amazon build a chromium webview ( for its Kindle devices. we are launching on it, and performance is great, as expected; although  you have no control over the webview

Comment 82 Deleted

Can this amazon stuff be built for regular android devices?
If you happen to be at GDC Next, I will be presenting our findings in the "Porting Realm of Empires from Facebook to Mobile HTML5" presentation, which will be followed by an article with more detail. In a nutshell, Amazon build a chromium base webview, that they expose to us as a... browser, that the best way I can put it (see They call it "Amazon WebApp". They say that "webapps" will work on all android devices 2.3 and higher, which implies chromium webview, but actually chromium web view is only available for Kind Fire devices; on other androids your app will run in a regular Android's webview (which we found works differently then our app that wraps the android's webview itself, don't know yet why).  So if you want to optimize for Kindle, you have chromium as an option. We have not yet looked at their chromuium vs chrome on mobile. If you want more info once article / presentation is out, just catch me on

Comment 85 by, Oct 24 2013

We have large enterprise clients that we have had to tell not to use Android and are driving sales to Apple. For us, there is no other option. The android experience is so bad that we cannot even show customers. What is sad, I carry a Note 2 that I will not even run my own app on.
Last time I investigated this issue, I found a project called "ChromeView" that looked promissing:
I did not tested it.

All the other area I investigated where either too complicated to run, either not working as expected:
- Chrome Content Shell and Content Module:
- Projet Chromium Embedded Framework
- Chrome Android build insructions:

There is also a bug (with patches) related to running a FirefoxWebview:

Comment 87 by, Oct 24 2013

HW acceleration works on some devices and not on others.  Turning it on can
reduce performance on some Androids from my experience.  There is NO silver
bullet except for running your app outside of the browser.

ChomeView is about 1 year away from being production ready.

My games does fullscreen refreshes with over animations 20+ animations
running at the same time.  UIWebView on Android is just horrible.  Writing
stuff by abstracting rendering is really the way of the future.  You should
be rendering your code in whatever is best for the device/OS

That's my 2 cents.


Comment 88 by, Oct 24 2013

Oh,  Intel XDK,, and Ludei (CocoonJS) would agree with me and have
the same philosophy that I do around Android WebView.  That is dont' use it.

Great news! Android 4.4 (KitKat) will be shipped with the Chrome WebView as a default: 

Comment 90 by, Oct 31 2013

Great!  If there is any way we could get this so we can package this with
android apps < 4.4?

Comment 91 by, Oct 31 2013


On its own, this doesn't solve the problem of providing a consistent experience across versions of Android. At the same time, having the source code means it should be possible to get all the bits into a library.

Comment 92 by, Oct 31 2013

Sounds good. But if you read it it doesn't include WebGL, Audio or RTC. Which kind of simply makes it a nicer JS / rendering engine.

Kind of sucks really. I was hoping for apps including games, art etc. Guess we're going to have to wait another year to six months for this one.

Comment 93 by, Oct 31 2013

Games on android HAVE to be done with an accel. layer like Cocoon or
EjectaX.  There is just no way around it.  Android WebView performance is
just so bad.

Comment 94 by, Oct 31 2013

But this would have allowed WebGL / good JS. Which would have meant good
performance. Hence, alas.

Tarwin Stroh-Spijer

Comment 95 by, Oct 31 2013

WebGL does not imply good JavaScript.  These are two different things.  One
thing that we have done as a team, is create our game in a way that is
rendering agnostic.  This way, you can switch between all these different
rendering paradigms (CSS/Canvas/WebGL) without changing much code.  Tying
an app to a single rendering paradigm is bad IMHO.


Comment 96 by, Oct 31 2013

I get the excitement over new features, but the still ongoing performance issues with Chrome make me skeptical. I fear my users will experience more lagging/jittering/stuttering in my apps now.

Just look at the The Verge's article about Nexus 5. It peforms great, except Chrome, as usual. And the comment section is filled with complains about Chrome's performance, that is not a general Android problem anymore.

Comment 97 by, Nov 1 2013

strangely enough looks like Android is not priority for chrome team ,
meanwhile Firefox is working towards Gecko View here is sample app ->

it adds around 18 mb to ur app but I guess its anything is better than
super slow and crappy webview

GeckoView will have all the support which Firefox itself , as its will
power Firefox on Android

After testing ....I am going open ticket with apache cordova /phonegap to
replace webview with GECKO view ..or submit the patch itself

man this is so frustrating , google kind of web and browser innovation is
SOOOOO SLOW to innovate on its own mobile os

Comment 98 Deleted

click "Check them out" under "Even more features"

Chrome web view

Applications that embed web content now use Chrome to render web components accurately and quickly.
Labels: Cr-Mobile-WebView
Status: Fixed
Thanks for the lively input here everyone, it's been encouraging to follow.

The conversation is starting to circle now, so given the public announcement in Android 4.4. I'm going to boldly jump in and mark this Fixed now :-)

For those interested, the exact code shipping in 4.4 is being uploaded to AOSP e.g.

I agree there are some loose ends that were discussed in this thread that are not there in 4,4. I suggest where people are interested, these should be broken into distinct new issues to keep any further discussion focused. e.g.

- Making a chromium available as a static library for APKs to include

- Adding web platform features that are already present in Chrome for Android; e.g. webgl, webrtc, etc..

- The ability to update WebView implementation independent of OS updates.

(if you can, please add the 'Cr-Mobile-WebView' on any issues raised)


Thank you Google for your efforts on this!!!  It's great to see the KitKat
embedded browser take on the vast majority of Chrome's goodness.
Chromium WebView is faster but it broke a lot of existing application.
Would be nice to have some backward compatibility.
Please star this issue:

Comment 103 by, Dec 15 2013

html5 canvas is not hardware accelerated. Rendering performance is extremely poor. Please star these issue if you agree :
@ "- Making a chromium available as a static library for APKs to include"

Is this already an ongoing effort somewhere? If yes, where can I follow this?
> @ "- Making a chromium available as a static library for APKs to include"

> Is this already an ongoing effort somewhere? If yes, where can I follow this?

No. Feel free to open a new bug for discussion and paste the bug number back here.

Comment 106 by, Dec 19 2013

boliu: I beg to differ. I think the bug below asks for that. At least I intended it to, sorry if my description wasn't clear. 
I just recently stumbled across the Crosswalk Project from Intel.  It's exactly what we've all been hoping for - the ability to easily embed Chromium in to our APKs.

Fantastic stuff.  The performance is great.

Components: -UI>OSIntegration Internals>PlatformIntegration
Showing comments 9 - 108 of 108 Older

Sign in to add a comment