Сделать так, чтобы #webview отрабатывал всегда, а не только раз в день? Это можно будет поменять в настройках.

15-я сборка #webview!

1) WebView теперь по умолчанию запускается при каждом подключении к MosMetroV2 (см. голосование чуть выше). Это можно отключить в меню "Настройки подключения" - "pref_webview_always" (снять галочку).

2) В лог теперь пишется адрес, который приложение выбрало для проверки интернета. То же самое происходит и в ветке master.

3) Добавлена опция pref_webview_debug, которая тормозит подключение на странице авторизации и позволяет подключиться к WebView через удалённую отладку Chrome. Это временная опция, которая будет удалена в полноценном релизе (скорее всего). Подробнее об удалённой отладке: https://developers.google.com/web/tools/chrome-devtools/remote-debugging/

4) Добавлена опция pref_debug_force_MosMetroV2, которая позволяет тестировать WebView откуда угодно, а не только в сети MT_FREE. Это тоже временная опция, которой точно не будет в релизе.

5) Окно WebView теперь имеет размер не 0x0 пикселей, а 1x1. Во время активности WebView вы можете заметить мигающий пиксель в левом верхнем углу экрана. Это сделано для того, чтобы при удалённой отладке WebView работала не только консоль JavaScript, но и было видно, что показывает WebView. Как и предыдущие два пункта, это изменение будет отменено в будущем.

Скачать сборку можно через встроенные обновления, либо по этой ссылке: https://mosmetro.duckdns.org/api/v1/download.php?branch=webview

Сразу же 16-я сборка #webview. Подправил таймауты, т.к. оказалось, что по умолчанию на загрузку страницы даётся только 25 секунд, чего чаще всего не хватает. Сделал 60 секунд. Будем надеяться, что этого хватит. Ссылка из поста выше теперь ведёт на эту сборку.

Оказалось, что я так и не удалил старую функцию имитации загрузки ресурсов из ветки #webview. В результате получилось, что сначала WebView скачивает страницу авторизации и все ресурсы с неё, а затем приложение повторяет ту же операцию. А так как WebView видит больше ресурсов, получается каскад из кучи загрузок (даже несколько видео).

В 18-й сборке удалил эту функцию. Если WebView будет работать нормально, то эта она всё равно уже не пригодится.

Кроме этого изменения в 18-й сборке ничего нет, так что можно просто зайти в "Настройки подключения" и снять галочку с "Имитация загрузки ресурсов (бета)". Но проще же APK скачать? :)

Скачать сборку можно через встроенные обновления, либо по этой ссылке: https://mosmetro.duckdns.org/api/v1/download.php?branch=webview

18-я сборка #webview почти всегда зависает на ожидании страницы авторизации. Раньше этой проблемы не было, т.к. WebView работал неправильно и не доходил до этого этапа.

Пока что заметил там сразу несколько проблем:

1) WebView пытается загружать ресурсы в несколько потоков, а собственный HTTP-клиент может работать только синхронно. Из-за этого некоторые ресурсы теряются или приложение вообще падает с ошибкой.

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

Пока эти проблемы не будут исправлены, подключиться можно будет только отключив pref_webview_enabled в настройках.

По идее, можно подключаться по следующему алгоритму, который окажет на блокировки примерно тот же эффект, что и нормально работающий WebView (если этот эффект вообще есть):

1) Попытаться подключиться с включённым WebView. Если не зависнет, то вообще отлично.

2) В случае падения с ошибкой можно попробовать отключить многопроцессорность WebView в настройках для разработчика. После этого повторить пункт 1.

3) В случае зависания подождать секунд 30, нажать на кнопку "Остановить", зайти в настройки и отключить pref_webview_enabled.

4) Снова попытаться зайти через ручное подключение (должно сработать очень быстро).

Постараюсь исправить эти проблемы в ближайшие дни, но за ними может быть ещё много неожиданного.

В 19-й сборке #webview было исправлено падение приложения при многопоточном WebView, а также поведение таймаутов стало корректным (до этого они вообще неправильно работали).

С основной проблемой (пункт 2 в предыдущем сообщении) так пока и не разобрался. Удалось выяснить, что с самим JavaScript всё отлично — он вызывается, отрабатывает и моментально возвращает корректное значение. Но дальше происходит странное: синхронизатор почему-то теряет это значение и выпадает по таймауту. Сначала подумал, что проблема в классе Listener, но с обычными переменными это тоже не работает. Кажется, что ошибка в чём-то простом, но найти её не могу пока. Чуть позже попробую ещё раз.

Определить "зависание" теперь можно по повторяющейся строчке TimeoutException в расширенном логе подключения. В этом случае можно попробовать остановить подключение с запустить его заново. В крайнем случае придётся снова отключить опцию pref_webview_always в настройках подключения.

Скачать сборку можно через встроенные обновления, либо по этой ссылке: https://mosmetro.duckdns.org/api/v1/download.php?branch=webview

Наконец-то исправил баг с зависанием в 20-й сборке #webview! По крайней мере теперь он не воспроизводится в домашних условиях. Остальное покажут тесты.

Так и не понял, в чём была проблема, но решилась она передачей объекта в виде аргумента функции, а не обращение к нему через экземпляр Synchronizer. Наверно Handler.post() что-то странное творит с объектами. Или это какая-то особая магия Java. Ну или это я слишком мало знаю Java :)
https://github.com/mosmetro-android/mosmetro-android/commit/25fe321768b5d4db75cca4cbae4710518855b512

При этом сразу же вылезла новая проблема: Listener стал выпадать с ошибкой ConcurrentModificationException несмотря на то, что там всё синхронизировано. Проблема решилась переходом с LinkedList на ConcurrentLinkedQueue. Но теперь придётся пересматривать мои знания о synchronized блоках и методах ._.
https://github.com/mosmetro-android/mosmetro-android/commit/7e4930c37e0b95618a0e0ab736ce2275535ed8f2

Теперь во время ожидания полной загрузки страницы приложение будет выводить в расширенный лог строки false или ошибки до тех пор, пока не появится строка true. Обычно это происходит меньше, чем за 10 секунд.

Скачать сборку, как и всегда, можно через встроенные обновления, либо по этой ссылке: https://mosmetro.duckdns.org/api/v1/download.php?branch=webview

Ура, новые "проблемы"! На этот раз в #webview всё работает, но есть, что улучшить:

1. Если в WebView запускается рекламный ролик, то прерывается воспроизведение музыки или видео на устройстве. Самой рекламы при этом не слышно, т.к. для включения звука там надо специально на кнопку нажать. Возможно, что видео не будет воспроизводиться, когда я снова сделаю окно 0x0 пикселей.

2. Сейчас WebView слабо интегрирован в процесс подключения. По сути, алгоритм остался прежним, просто перед ним запускается браузер. Это приводит к тому, что приложение не может распознать полученную блокировку и другие крайние случаи – вместо этого оно зависнет на ожидании полной загрузки страницы.

3. Пока не разбирался, в чём причина, но у меня подключение прошло три раза: сначала успешно, потом "уже подключено", затем снова успешно. И всё это в пределах минуты. При этом каждый раз запускался WebView и кликал на кнопку входа. По идее, проблема должна исчезнуть после исправления пункта 2.

На этот раз проблемы не такие серьёзные и, по сути, всё работает в пределах нормы. Можно включать pref_webview_enabled и _always и наслаждаться отсутствием необходимости запускать браузер :)

Небольшое обновление для #webview. Теперь подключение не зависнет на ожидании загрузки страницы при недоступном DNS.

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

Скачать сборку, как и всегда, можно через встроенные обновления, либо по этой ссылке: https://mosmetro.duckdns.org/api/v1/download.php?branch=webview

Что-то я поторопился, когда сказал, что пробросить ошибку невозможно. Напрямую её пробросить и правда нельзя, но нам и не нужно, чтобы WebView о ней знал. В общем, 22-я сборка #webview теперь возвращает пустой ответ, чтобы WebView не пытался загрузить страницу сам, а также уведомляет остальные части приложения об ошибке DNS. Так и надо было изначально сделать :)

В 23-й сборке #webview отключил отладку Chrome и вернул панели браузера размер 0x0 пикселей. Опции pref_webview_debug и pref_debug_force_MosMetroV2, соответственно, тоже удалены. Это должно предотвратить прерывание музыки в случае включения видео в браузере (теперь видео просто не включится).

Также это может предотвратить вылеты, которые связаны с каким-то багом в Chrome. Если 23-я сборка всё-таки продолжит вылетать, присылайте логи из программы CatLog https://play.google.com/store/apps/details?id=com.nolanlawson.logcat (требуется root) мне в ЛС (@TheDrHax). Спасибо!

Небольшие обновления в ветках #master и #webview.

* Наконец-то я переборол свой страх перед "сложными" компонентами UI и сделал отображение логов на RecyclerView. Теперь приложение не должно падать, даже если лог очень сильно разрастётся. Теоретически, приложение всё ещё может упасть, если попытаться отправить огромный лог на почту, не предоставив доступ к внешней памяти, но это происходит слишком редко для того, чтобы запрещать такой способ отправки.

* Также удалось реализовать приостановку автоматической прогрутки, чтобы можно было спокойно листать лог, пока приложение что-то делает. Автопрокрутка возобновится, если пролистать лог обратно до конца.

* Из минусов RecyclerView: теперь нельзя выделять текст в окне ручного подключения. Дело в том, что каждая строка лога теперь представлена отдельным элементом TextView. Возможно, в будущем получится что-нибудь с этим сделать.

* Ну и совсем мелкое изменение: кнопка создания ярлыка снова вернулась в главное меню, а то совсем уж она не вписывалась в окно ручного подключения.

Кстати, тикет по поводу падений из-за огромного лога висел аж с 4 декабря прошлого года. Исправление заняло полчаса =\
https://github.com/mosmetro-android/mosmetro-android/issues/187

Скачать сборку, как и всегда, можно через встроенные обновления, либо по этим ссылкам:
master - https://mosmetro.duckdns.org/api/v1/download.php?branch=master
webview - https://mosmetro.duckdns.org/api/v1/download.php?branch=webview

Насколько более эффективен новый механизм отображения лога? На видео я записал в лог 250000 сообщений. До обновления приложение выпадало с ошибкой выделения памяти, а тут даже не тормозит :)

Сегодня вышла 25-я сборка #webview, в которой был немного обновлён список адресов generate_204. По идее, это должно починить сообщение "Уже подключено" перед авторизацией.

Оказалось, что либо провайдер пропускает запросы к некоторым серверам Google, либо самостоятельно отвечает кодом 204. Не знаю, специально они это сделали или у них была какая-то своя причина. Данная проблема не должна была затронуть остальные ветки, т.к. они использовали правильные два адреса вместо случайного списка.

Изменение: https://github.com/mosmetro-android/mosmetro-android/commit/d9817e111e41bc0da8ef810809bac7bea6f8ea72
Ссылка на актуальную сборку (встроенные обновления тоже работают): https://mosmetro.duckdns.org/api/v1/download.php?branch=webview

350-я сборка #master + обновление ветки #adaptive-icons.

Изменение полностью совпадает с тем, что было сделано в 25-й сборке #webview (см. выше). Сначала думал, что эта проблема не затрагивает остальные ветки, но оказалось, что я смотрел не на ту версию исходного кода.

В ветке adaptive-icons всё по прежнему — совпадает с master (немного отстаёт), использует новый Android SDK, но есть регрессии: https://github.com/mosmetro-android/mosmetro-android/pull/198

Ссылки на актуальные сборки:
master — https://mosmetro.duckdns.org/api/v1/download.php?branch=master
adaptive-icons — https://mosmetro.duckdns.org/api/v1/download.php?branch=adaptive-icons

Только что появилась новая ветка обновления #welcome-spb, которая должна избавить алгоритм MosMetroV2 от старого костыля с обходом welcome.wi-fi.ru. Эта сборка основана на ветке master, а webview я обновлю, если всё заработает.

Новый алгоритм MosMetroV3 активируется, когда устройство получает перенаправление на адрес welcome.wi-fi.ru. Есть три возможных результата его работы:
1. Интернет появился — работа алгоритма завершается;
2. Снова получено перенаправление на welcome.wi-fi.ru — выпадает ошибка о бесконечном цикле, т.к. пока не ясно, что делать дальше;
3. Получено какое-то другое перенаправление, с которым приложение умеет работать — активируется соответствующий алгоритм и пытается подключиться, как обычно.

В первую очередь алгоритм MosMetroV3 может помочь в сетях Санкт-Петербурга, т.к. там приложение больше не работает. Я подозреваю, что это именно из-за welcome.wi-fi.ru, но убедиться в этом получится только опытным путём.

Пока что по поводу welcome.wi-fi.ru известно следующее:
1. Адрес недоступен из интернета (в отличие от auth.wi-fi.ru);
2. Перенаправление с этим адресом выдаётся не всегда — либо он ещё тестируется, либо просто работает случайно;
3. Судя по всему, полное выполнение алгоритма с welcome не приводит к появлению доступа в интернет. После него идёт перенаправление на auth, т.е. в любом случае нужно проходить авторизацию по старому алгоритму;
4. Welcome легко обходится подменой домена на auth, за счёт чего до сих пор нормально работают даже версии из Google Play. Однако в Санкт-Петербурге, судя по дампам, это может вызывать ошибку подключения.

Из-за первого пункта в данный момент я не могу проверить, работает ли вообще этот алгоритм. Если увидите в логе MosMetroV3, то пришлите, пожалуйста, лог мне на почту или в ЛС @TheDrHax. Напомню, что это можно сделать из окна ручного подключения кнопкой в верхней панели. Спасибо!

Ссылка на актуальную сборку: https://mosmetro.duckdns.org/api/v1/download.php?branch=welcome-spb

2-я сборка ветки #welcome-spb!

* Немного почищен лог: в него попадали ошибки из-за inline-изображений (base64 в атрибуте src), которые раньше не применялись на страницах авторизации.
* Найдена и исправлена опечатка на втором шаге алгоритма MosMetroV3. Именно на этом шаге у всех возникала одна и та же ошибка Unexpected answer: false.

У меня так и не было возможности проверить эту сборку в деле. В следующих шагах (а их ещё минимум 3) также могут быть ошибки, так что буду рад логам. Спасибо :)

У данной ветки обновления появилась страница на GitHub, на которой можно отслеживать прогресс: https://github.com/mosmetro-android/mosmetro-android/pull/208
Ссылка на актуальную сборку осталась прежней: https://mosmetro.duckdns.org/api/v1/download.php?branch=welcome-spb

Актуальные ссылки на сборки приложения

Основные ветки:

#master - основная ветка, в которой раньше всего появляются стабильные улучшения или исправления - APK

#play - совпадает с версией из Google Play, давно не обновлялась - APK

#beta - совпадает с бета-версией из Google Play или веткой play, если та содержит более новую версию - APK

Экспериментальные ветки:

#webview - эксперимент по внедрению браузера в приложение, смотрит рекламу в фоновом режиме, гораздо реже ловит баны, но глючит (прерывает музыку или зацикливается, а иногда может даже вылетать) - APK

#adaptive-icons - содержит реализацию новых иконок для Android 8.1; из-за перехода на новую версию API некоторые вещи работают неправильно, поэтому это изменение до сих пор не попало в master - APK, GitHub

#sdk-27 - экспериментальный переход на SDK версии 27 (Android 8.1); половина вещей не работает, особенно — автоматическое подключение и работа с Wi-Fi; та же adaptive-icons, только без иконок - APK, GitHub

Ссылки не работают? Нужна конкретная  сборка конкретной ветки? Вы можете загрузить любую сборку напрямую из Jenkins.

Не знаете, какую ветку выбрать? Попробуйте начать с master. Если она будет часто ловить блокировки от провайдера, то можете попробовать переключиться на webview.

Как менять ветки? Помимо простого скачивания APK по ссылке выше вы можете выбрать ветку обновления в главном меню приложения (пункт "Ветка обновления"). Если в списке отображается только одна сборка, проверьте доступ в интернет и нажмите "Проверить наличие обновлений" в главном меню.

Сборка не устанавливается? Такое может случиться, если текущая установленная сборка имеет другую цифровую подпись (из F-Droid или от неофициальных сборщиков) или более новую версию (даунгрейд не поддерживается в Android). Просто удалите текущую установленную версию и попробуйте снова.

Пост будет обновляться по мере изменения основного набора веток обновления.

4-я сборка #welcome-spb! 2-я успешно себя показала во многих сетях, в том числе и в Санкт-Петербурге.

В этой сборке был убран один лишний запрос, немного почищен лог, новые сообщения переведены на русский язык.

Скоро можно будет провести слияние этой ветки с master, но сначала нужно ещё раз проверить её в сетях Москвы и Санкт-Петербурга. Напомню, что полезными являются любые логи с упоминанием алгоритма MosMetroV3, даже если потом в нём упоминается MosMetroV2 (так и должно быть).

Спасибо всем, кто присылает логи! Без вас мне пришлось бы самому ехать в Санкт-Петербург :)

Ссылка на актуальную сборку осталась прежней: https://mosmetro.duckdns.org/api/v1/download.php?branch=welcome-spb

351-я сборка #master, ветка #welcome-spb удалена! Пользователям ветки welcome-spb приложение должно само предложить обновиться до ветки master.

Что нового:
1. Поддержка welcome.wi-fi.ru (алгоритм MosMetroV3), важная для работы в Санкт-Петербурге;
2. Новая настройка (Главное меню - Системный лог) — дублирует сообщения в системный лог, чтобы можно было собрать информацию даже если приложение аварийно завершится. Собрать лог можно либо через adb logcat, либо через приложение CatLog (нужны права root).

Вечно актуальная ссылка на сборку: https://mosmetro.duckdns.org/api/v1/download.php?branch=master

P.S. До полноценного релиза осталось исправить работу приложения с новыми версиями Android 8+. Отслеживать прогресс и мою боль можно в тикете #197.
P.P.S. Обновление ветки #webview постараюсь сделать в ближайшее время. 2-й пункт был сделан именно для неё. Просто MosMetroV3 не очень сочетается с тем, что там уже есть.