From: Daniel Micay Date: Thu, 26 Jan 2017 01:30:12 -0500 Subject: Use 64-bit WebView processes 64-bit processes introduce 10% or so higher memory consumption. The reason for preferring 64-bit processes is providing substantially better exploit mitigations at the expense of slightly more memory usage. In addition to the standard mitigations, it also enables usage of https://github.com/AndroidHardening/hardened_malloc (where available). It will provide high entropy ASLR (24-bit to 32-bit depending on whether the kernel uses 3 or 4 level page tables rather than 16-bit for 32-bit processes), high entropy stack canaries (56/64-bit instead of 24/32-bit depending on whether a zero byte is used) and also features like pointer authentication and memory tagging when those are made available in the future. The reason why upstream started preferring 32-bit processes is to save memory, particularly since saving memory makes it feasible to use finer-grained sandboxing. --- android_webview/nonembedded/java/AndroidManifest.xml | 1 - 1 file changed, 1 deletion(-) diff --git a/android_webview/nonembedded/java/AndroidManifest.xml b/android_webview/nonembedded/java/AndroidManifest.xml --- a/android_webview/nonembedded/java/AndroidManifest.xml +++ b/android_webview/nonembedded/java/AndroidManifest.xml @@ -28,7 +28,6 @@ android:icon="@{{manifest_package|default('com.android.webview')}}:drawable/icon_webview" android:name="{{ application_name|default('org.chromium.android_webview.nonembedded.WebViewApkApplication') }}" android:multiArch="true" - {{ use32bitAbi|default('android:use32bitAbi="true"') }} android:extractNativeLibs="{{ trichrome_library is not defined }}"> {# This part is shared between stand-alone WebView and Monochrome #} {% macro common(manifest_package, webview_lib) %} -- 2.17.1