на эмуляторе метод shouldInterceptRequest(WebView view , WebResourceRequest request) класса WebViewClient, а именно параметр request, при преобразовании его в Uri, может содержать в себе, например как "data:text/html;charset=utf-8;base64," так и "file:///Image/etc.png", а на реальном девайсе он содержит только "data:text/html;charset=utf-8;base64,"?
Версии WebView могут быть разные не девайсах, например.
Так, а что мне в таком случае делать?)
пердеть и бегать! делать с чем? Чтобы для чего?
потому что это ури разных объектов, с разными схемами
Да в жопу скрины. Воспроизводимка — код, который можно запустить и воспроизвести описанное поведение) После base64, должно идти, собственно, base64, подозреваю, что текст в логах урезанный
А-а-а, тьфу ты. Ну с воспроизводимкой есть определенные трудности, т.к. приложение-то по-сути древнее легаси, что означает, что мне придётся "выскабливать" половину приложения ради простого воспроизведения поведения) Поэтому ладно, придётся опять выдумывать костыли и лисопеды.
посмотри на УРИ хотя б в дебаггере)
Ага! Я нашёл в чём проблема! Оказывается, судя вот этому файлу из доки с 30 SDK WebView по-дефолту запрещает ссылки типа "file:///". А вот этот фрагмент мне помог: WebSettings webViewSettings = webView.getSettings(); // Setting this off for security. Off by default for SDK versions >= 16. webViewSettings.setAllowFileAccessFromFileURLs(true); // Off by default, deprecated for SDK versions >= 30. webViewSettings.setAllowUniversalAccessFromFileURLs(true); // Keeping these off is less critical but still a good idea, especially if your app is not // using file:// or content:// URLs. webViewSettings.setAllowFileAccess(true); webViewSettings.setAllowContentAccess(true); P.s: вот и спрашивается, зачем такой, блен, геморрой?
Красава! Анально огородились, блин. Чего стоит один только отключённый по умолчанию жабоскрипт.
чтобы включать нужное вместо выключения всего ненужного
Обсуждают сегодня