Как и зачем мы затащили GeckoView в Почту

Начиная с июня 2023 года мы стали получать жалобы от пользователей о том, что у них не отображаются письма в Android-клиенте Почты Mail.ru. В ходе исследования мы даже приглашали пользователя к нам в офис для отладки. В конце концов мы поняли, что проблема на стороне WebView, компонента, с помощью которого мы можем отображать веб страницы. Ни для кого не секрет, что WebView используется во многих банковских и почтовых клиентах, в приложениях интернет-магазинов, сервисов доставки и многих других. Также изучили другие почтовые сервисы, нам хотелось понять, как они с этим справились. Оказалось — никак :)

Обнаружение проблемы

Сначала мы реализовали простой способ обнаружения проблемы:

class JSCheckWorksInterface(private val successCallback: () -> Unit) {
   @Keep
   @JavascriptInterface
   fun webViewWorks() {
       successCallback()
   }
}


val jsInterface = JSCheckWorksInterface {
   // код выполнится, если WebView работает :)
}


webView.addJavascriptInterface(jsInterface, "CheckWebViewWorksBridge")
webView.loadUrl("javascript: void CheckWebViewWorksBridge.webViewWorks();")

Здесь мы ожидаем коллбек из JsBridge, и если не получаем его в течение определённого таймаута, то считаем, что с WebView что-то не так. Затем мы добавили в приложение диалог с инструкцией, как пользователю самостоятельно починить WebView. Но, во-первых, даже с инструкцией не все пользователи понимали, что нужно делать, а во-вторых, это помогало лишь временно.

Альтернативные методы чтения писем

Судя по ответу на issue, Google о проблеме давно знает и решать её не собирается. Дело в том, то с ней сталкивается лишь очень небольшая доля пользователей некоторых версий Android. Мы точно знаем про Android 10 и единичные случаи на Android 14. Вот только нашим почтовым клиентом пользуются десятки миллионов людей, и, по результатам нашей аналитики, с этой проблемой ежедневно сталкиваются десятки тысяч пользователей. Мы понимали, что это далеко не последняя проблема, связанная с WebView и хотелось бы защититься от потенциального повторения подобного. Тогда мы решили, что хотим иметь не зависимое от WebView решение для отображения писем, которое мы со своей стороны сможем контролировать и тем самым обеспечить бесперебойный доступ пользователей к критически важному функциональности — чтению писем.

Какие варианты мы рассмотрели:

• Просмотр писем в виде PDF;

• Просмотр писем в виде текста в обычной TextView;

• Сделать свой WebView на основе Chromium;

• Интегрировать GeckoView.

Мы остановились на последнем. Gecko — это браузерный движок, разработанный в Mozilla. GeckoView — это как бы «обёртка» над Gecko, оформленная в виде отдельной библиотеки. И, так как GeckoView весит немало, было решено попытаться удалить из неё всё, что не нужно, пересобрать и распространять её точечно для пользователей со сломанным WebView. А сделать это можно только с помощью Dynamic Feature Delivery. Этот инструмент позволяет выносить модули приложения из основного APK и доставлять их пользователям, например, когда они хотят воспользоваться нашей фичей, и удалять эти модули, если они уже не нужны. Благодаря этому даже тяжёлый GeckoView не повлияет на размер основного APK. Здесь мы расскажем про самые неочевидные проблемы, с которыми мы столкнулись при работе с самим GeckoView и при его интеграции в Dynamic Feature Delivery.

Неочевидные нюансы

Сначала мы вынесли работу с WebView в чтении писем под интерфейс и сделали альтернативную реализацию для GeckoView. Самая первая проблема, с которой мы столкнулись — неочевидное падение в базе данных при попытке создания GeckoView. Казалось бы, как связан кеш писем, и рендер HTML‑страниц в GeckoView? Дело в том, что GeckoView для своей работы создаёт отдельные процессы нашего приложения, в которых, разумеется, вызывается Application.onCreate(). Как известно, в Application.onCreate(), зачастую, происходит инициализация многих компонентов приложения, некоторые из которых строго завязаны на главный процесс приложения. Решение простое: проверяем, в каком процессе мы находимся, и в зависимости от этого решаем, нужно ли нам инициализировать все наши компоненты:

override fun onCreate() {
    super.onCreate()
    if (!isOnMainProcess(this)) {
        return
    }
 
    // set up applcation
}


    fun isOnMainProcess(context: Context): Boolean {
        val runningAppProcesses = getActivityManager(context).runningAppProcesses
        val myPid = Process.myPid()
        val packageName = context.packageName
        return if (runningAppProcesses.isNullOrEmpty()) {
            val processName = getProcessName()
            if (processName.isNullOrEmpty()) {
                true
            } else {
                processName == packageName
            }
        } else {
            runningAppProcesses.any {
                val isCurrentProcess = it.pid == myPid
                val isMainProcessName = it.processName == packageName
                isCurrentProcess && isMainProcessName
            }
        }
    }

Следующими нашими граблями стало падение при инициализации нативных библиотек. Оказалось, что очень важен правильный порядок инициализации:

    fun loadNativeLibraries(context: Context) {
        loadLibrary(context, "freebl3")
        loadLibrary(context, "ipcclientcerts")
        loadLibrary(context, "lgpllibs")
        loadLibrary(context, "mozavcodec")
        loadLibrary(context, "mozavutil")
        loadLibrary(context, "mozglue")
        loadLibrary(context, "nss3")
        loadLibrary(context, "nssckbi")
        loadLibrary(context, "plugin-container")
        loadLibrary(context, "softokn3")
        loadLibrary(context, "xul")
    }


    private fun loadLibrary(context: Context, libName: String) {
        try {
            SplitInstallHelper.loadLibrary(context, libName)
        } catch (e: UnsatisfiedLinkError) {
            Log.e(TAG, "Native libraries not loaded", e)
        }
    }

Далее, мы заметили, что при использовании Dynamic Feature у нас дублируются сервисы GeckoView в манифесте и GeckoView считало, что может запускать вдвое больше сервисов, чем на самом деле. В итоге мы ловили падение с вероятностью 50/50. Пришлось зафиксировать количество сервисов в коде GeckoView:

public static int getServiceCount(
   @NonNull final Context context,
   @NonNull final GeckoProcessType type
) {
 if (type == GeckoProcessType.CONTENT) {
   return 30;
}

Разумеется, GeckoView не столь популярное решение, поэтому далеко не на всех устройствах оно работало одинаково. Где-то всё было хорошо, а где-то — много различных артефактов. Стабилизировать работу GeckoView нам помог метод setViewBackend(BACKEND_TEXTURE_VIEW) у GeckoView. Теперь всё работает одинаково и предсказуемо на всех устройствах. Одним из важных факторов при работе с движком отображения писем для нас было наличие API, позволяющего контролировать и переопределять сетевые запросы. Например, при загрузке картинок, встроенных в письмо, мы должны прокидывать различные дополнительные параметры. В WebViewClient для этого есть метод shouldInterceptRequest(). С его помощью мы можем контролировать сетевые запросы в нативном коде и делать с ними что угодно, даже, например, кешировать картинки. В GeckoView нам не удалось найти такой же простой способ управления запросами, поэтому, покопавшись в документации, мы решили приспособить для наших целей механизм WebExtensions. К сожалению, для этого пришлось немного потрогать JavaScript:

let port = browser.runtime.connectNative("InterceptorApp");
let customParam = null;
 
function onBeforeRequest(requestDetails) {
    let redirectUrl;
    try {
        redirectUrl = new URL(requestDetails.url);
    } catch {
        return;
    }
 
    if (!!customParam && !redirectUrl.searchParams.get("customParam")) {
        redirectUrl.searchParams.append("customParam", customParam);
        // return обязательно внутри этого "if", иначе будем бесконечно попадать в onBeforeRequest
        return { redirectUrl: redirectUrl.href };
    }
}
 
port.onMessage.addListener(response => {
    customParam = response.customParam;
});
 
browser.webRequest.onBeforeRequest.addListener(
    onBeforeRequest,
    { urls: ["<all_urls>"] },
    ["blocking"]
);

Подключение к WebExtension занимает несколько секунд. Поэтому мы загружаем веб-страницу только тогда, когда порт взаимодействия с WebExtension становится доступен. Так мы гарантируем, что наши дополнительные параметры обязательно попадут в запрос, хотя придётся немного подождать.

class GeckoExtensionPortHolder {
    var port: Port? = null
        set(value) {
            field = value
            onPortAvailableListeners.forEach {
                it.invoke(field)
            }
            onPortAvailableListeners.clear()
        }


    private val onPortAvailableListeners: MutableList<(Port?) -> Unit> =
        mutableListOf()


    fun executeOnPortAvailable(action: (Port?) -> Unit) {
        val port = this.port


        if (port != null) {
            action.invoke(port)
        } else {
            onPortAvailableListeners.add(action)
        }
    }


    fun onPortInitializationError() {
        // handle error
    }


    fun clear() {
        this.port = null
    }
}

Затем напишем код для подключения расширения из нашего Kotlin-кода:

    private fun installInterceptionExtension(runtime: GeckoRuntime) {
        val portDelegate = object : WebExtension.PortDelegate {
            override fun onDisconnect(port: WebExtension.Port) {
                if (portHolder.port === port) {
                    portHolder.clear()
                }
            }
        }
 
        val messageDelegate = object : WebExtension.MessageDelegate {
            override fun onConnect(port: WebExtension.Port) {
                portHolder.setPort(port)
                port.setDelegate(portDelegate)
            }
        }
 
        runtime.webExtensionController.ensureBuiltIn(EXTENSION_LOCATION, EXTENSION_ID)
            .accept({ extension ->
                extension?.setMessageDelegate(messageDelegate, EXTENSION_APP_ID)
            }, { throwable ->
                portHolder.onPortInitializationError()
            })
    }
 
    companion object {
        private const val EXTENSION_LOCATION = "resource://android/assets/interception/"
        private const val EXTENSION_APP_ID = "InterceptorApp"
        private const val EXTENSION_ID = "interception@mail.ru"
    }

А теперь можно передать нужные нам параметры в WebExtension перед загрузкой контента:

val put = JSONObject().put("customParam", customParam) 
portHolder.executeOnPortAvailable { port ->
    port?.postMessage(put)
        session.load(loader)
}

Изначально мы интегрировали GeckoView как динамическую фичу, и после исправления самых критичных проблем решили протестировать установку и запуск динамической фичи. Для этого в манифесте модуля с динамической фичей переключились с dist:install-time на dist:on-demand и выложили AAB в закрытое тестирование Google Play. Приложение упало с невнятным логом…

Дело в том, что GeckoView для нахождения пути к ассетам использует метод Context.getPackageResourcePath(). Затем нативный код сам пытался распарсить APK файл, чтобы найти в нём файл omni.ja и прочитать его содержимое. И это действительно работает, однако для Android 10 метод Context.getPackageResourcePath() возвращал путь к APK основного приложения, а не динамической фичи. Добавим sSplitApkPath и сделаем возможность проставлять её из самого приложения:

private static String sSplitApkPath = null;
 
public static void setSplitApkPath(String path) {
    sSplitApkPath = path;
}
 
private String[] getMainProcessArgs() {
    final Context context = GeckoAppShell.getApplicationContext();
    final ArrayList<String> args = new ArrayList<>();
 
    // argv[0] is the program name, which for us is the package name.
    args.add(context.getPackageName());
 
    if (!mInitInfo.xpcshell) {
        args.add("-greomni");
        if (sSplitApkPath != null) {
            args.add(sSplitApkPath);
        } else {
            args.add(context.getPackageResourcePath());
        }
    }
 
    if (mInitInfo.args != null) {
        args.addAll(Arrays.asList(mInitInfo.args));
    }
 
......
}

Затем пришлось написать костыль логику для нахождения правильного пути к APK динамической фичи, в которой находится omni.ja:

private fun findResourcePath(): String? {
    return findFromSplitSourceDirs() ?: findFromInternalDirs()
}
 
private fun findFromSplitSourceDirs(): String? {
    return context.applicationInfo?.splitSourceDirs?.find {
        it.contains("/split_geckoview.apk")
    }
}
 
private fun findFromInternalDirs(): String? {
    val dir = context.filesDir
    return findFile(dir, dir.absolutePath, "geckoview.apk")?.absolutePath;
}
 
private fun findFile(file: File, dir: String, name: String): File? {
    if (file.isFile()) {
        if (file.absolutePath.contains(dir) && file.getName().contains(name)) {
            return file
        }
    } else if (file.isDirectory()) {
        val listFiles = file.listFiles() ?: return null
        for (child in listFiles) {
            val found = findFile(child, dir, name)
            if (found != null) {
                return found
            }
        }
    }
    return null
}

Так выглядит итоговый код создания Runtime:

val settings = GeckoRuntimeSettings
            .Builder()
            .consoleOutput(true)
            .debugLogging(true)
            .pauseForDebugger(false)
            .build()
        settings.setConsoleOutputEnabled(true)
 
        GeckoThread.setSplitApkPath(findResourcePath())
        runtime = GeckoRuntime.create(context, settings)
        installInterceptionExtension(runtime)

Подведение итогов, плюсы и минусы такого решения

А теперь рассмотрим плюсы и минусы такого решения. WebView позволяет нам отображать AMP-письма, то есть делать их «интерактивными». Например, можно встраивать в них опросы, формы подтверждения бронирования или написания отзыва и многое другое. Такие письма на один шаг сокращают воронку, потому что пользователям не нужно переходить по ссылке и открывать браузер для совершения целевого действия. К сожалению, эта технология не поддерживается в GeckoView. Ещё в GeckoView могут возникать различные артефакты, хотя мы свели к минимуму их количество. Далось это непросто, потому что информации о работе с этим GeckoView, а в связке с Dynamic Feature Delivery — вообще нет. Не так много юзеров используют Gecko для отображения писем, однако теперь мы уверены, что в случае очередного кривого обновления, ломающего WebView, мы можем переключиться на GeckoView. Также к плюсам можно отнести то, что GeckoView можно довольно просто пересобрать под себя.

Надеемся это окажется для вас полезным!