Crosswalk Project - replacement of Android WebView. Project development

This review will continue a short series of two articles on an interesting project called Crosswalk. In it, I will talk about what has changed in the Crosswalk project since version 14.43.343.17 and whether it has become more convenient to use it now.

Let me remind you that the Crosswalk Project is a runtime built on open source technologies for HTML applications. The basis for the Crosswalk Project is Google Chromium. Crosswalk Project is also an open source project and is distributed under the BSD License . In general, if you still support earlier versions of Android, then this is a good replacement for the Android system WebView.

Previous articles can be found at the following links:

• Crosswalk Project - replacement of Android WebView. Project Integration
• Crosswalk Project - replacement of Android WebView. Integration issues

Changes in the crosswalk.

From version 14 to version 20, a lot of changes and improvements were made to the project, it does not make sense to list everything. You can read them yourself in release notes .

I will list only some of the most interesting ones:

• Rebase to chromium 50
• Support external extensions for Crosswalk Webview on Android
• Add ability to intercept touch events on the XWalkView
• When onReceivedLoadError occurs, there is a dialog
• New helper class XWalkInitializer to initialize XWalkView asynchronously
• Size optimizations (Enable ProGuard for Crosswalk to compress APK size, LZMA support etc.)

Also, the project made a large number of corrections, the most critical ones are listed there.

Additional details.

In previous articles I have described a number of problems and their solutions for previous versions of Crosswalk. I am glad that many of them are resolved in the project itself and now there is no need for “dancing with a tambourine”.

The XWalkCookieManager and XWalkSettings classes have been moved to more suitable packages for them :

org.xwalk.core.internal.XWalkCookieManager; → org.xwalk.core.XWalkCookieManager org.xwalk.core.internal.XWalkSettings → org.xwalk.core.XWalkSettings 

XWalkSettings is directly accessible through a method in an XWalkView object. Also, XWalkView itself can return us its User-Agent. Now for all this there is no need to resort to the use of reflection.

Added to the Crosswalk (to the XWalkResourceClient class) and a new call to handle requests to resources :

 public XWalkWebResourceResponse shouldInterceptLoadRequest(XWalkView view, XWalkWebResourceRequest request) 

Analogue very convenient and accessible with the Android API 21 call in the standard WebView:

 public WebResourceResponse shouldInterceptRequest (WebView view, WebResourceRequest request) 

Now you can easily find out by what method the request was made: GET or POST.

Also, a special method was added to XWalkView to get the image content :

 public void captureBitmapAsync(XWalkGetBitmapCallback callback) 

The onBackPressed () method was called correctly and the opportunity to use the setOnTouchListener (OnTouchListener l) method appeared. So now there is no need to intercept pressing the Back button and touch events in the dispatch methods.

Documentation on the latest and all previous API versions can be found here .

Some problems in new versions.

At the moment, the latest available version in the repository is 20.50.533.12, but unlike the penultimate version 19.49.514.5, it already has a minSdkVersion value equal to API 16. Crosswalk 19 still supports all Android versions starting from API 14.

Despite the fact that even for Crosswalk 16 it was stated: "Android support libraries (eg support-v4, support-v7 etc) are no longer bundled by Crosswalk ...". From version 16 to the last 20, the import for the support-v4 library is incorrectly registered, so if you use a specific version of this library in your project and do not want the project to automatically build with the latest version, then you need to exclude it when you add Crosswalk to your project :

 compile('org.xwalk:xwalk_core_library:19.49.514.5') { // avoid pulling incorrect version of support library exclude group: 'com.android.support', module: 'support-v4' } 

Crosswalk Lite, reduce build size.

In previous articles, I did not mention a fairly significant problem - increasing the size of the assembly when adding Crosswalk. Crosswalk itself is built for two architectures: x86 and armv7. Accordingly, the libraries for each of them have a size of ~ 20Mb, i.e. if you build a universal build, the overhead will be about 40Mb.

There are 2 ways to improve the situation with the additional size: collect separate apk for each architecture or use the light version of Crosswalk - Crosswalk Lite. Crosswalk Lite is an attempt to solve the problem by discarding some of the features of the library .

Here are more accurate data on Lite size and the regular Crosswalk version: Crosswalk Lite 10-15Mb vs. Crosswalk 20Mb.

However, besides the limited set of features, Crosswalk Lite has a number of disadvantages:

• Activity must be inherited from XWalkActivity;
• Application must inherit from XWalkApplication;
• Initialization must be carried out asynchronously in a special method, while on the first run the library itself is unpacked and the user sees a message about it.

Unfortunately, the latest currently available version of Crosswalk Lite 17.46.460.1 refused to start with an error (like 2 of its predecessor):

 W/XWalkInternalResources: org.xwalk.core.R$styleable.ButtonCompat is not int. E/SysUtils: ApplicationContext is null in ApplicationStatus A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 22829 (osswalkembedded) 

Therefore, the only realistic method for reducing the size is to build separate builds for each architecture.

Examples are added to the updated test project available on GitHub .

Findings.

In recent versions, many were taken into account, including the shortcomings of previous releases mentioned by me. And, if you are already using Crosswalk, then you definitely need to upgrade to new versions.

However, another question remains. Can Crosswalk now serve as a good replacement for the system WebView? If you support older versions of Android (including versions of Android 4 Jelly Bean and KitKat), then obviously Crosswalk can be useful to you. If you plan to support only Android 5+, then the answer here is not obvious.

From the 5th version of Android, an update of the system WebView from Google Play has become available (and new, convenient API requests have appeared), and from the 7th version of Android, Google Chrome is designed to replace the standard system component. How necessary an additional library in this case is difficult to say. Perhaps for some projects, the full identity of behavior on all versions of the OS outweighs the increase in size and the need to update another library.