В Android бывает так, что нужно срочно собрать логи, а предварительно adb logcat -v threadtime не сделали. Здесь выручает дамп логов: adb logcat -d -v threadtime. Но буфер логов, он ведь не бесконечный. А какой он? Можно ли им управлять?

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

Посмотреть: "adb logcat -g"
Изменить "adb logcat -G sizeK/M". То есть "adb logcat -G 256K" или "adb logcat -G 16M"

https://android-review.googlesource.com/q/platformcompat Кажется, в Android 11 появится возможность проверять ограничения платформы без необходимости выполнения adb команд или, по крайней мере, уменьшение числа команд, которые нужно запоминать: https://android-review.googlesource.com/q/platformcompat
Вот так это выглядит для приложения: https://www.xda-developers.com/files/2020/01/Android_11_App_Compatibility_Changes.jpg

За что я не люблю Самсунги. Даже китайцы себе такого не позволяют. А китайцы за цены, равные Самсунгу, оставляют его далеко позади.

Сегодня владельцы Samsung получили уведомление "Поиск мобильного устройства" с телом сообщения "1".

Самсунг тестирует на продакшене.

В Android 11, если пользователь ткнёт на Запрет пермишена дважды, то это будет равносильно "Запретить и больше не спрашивать". Надо сказать, это вообще не очевидно для пользователя. Многие до сих пор не знают, что App Picker тоже поддерживает двойной тап (но иначе) и что область уведомлений можно опустить ещё двумя пальцами.

И ещё из неочевидного для пользователя. Если в приложении есть WebView, то запрос на геолокации от веб вью не сильно связан с запросом от самого приложения. То есть для него это будет как 2 запроса от одного приложения.

Уточнение, потому как я неправильно написал. «Дважы» — это «Два раза». То есть третий раз приложение запросить разрешение не сможет.

Наконец Instagram не будет поднимать надоедливый запрос при каждом лишнем свайпе не в ту сторону.

Баг Telegram, который выглядит очень плохо. Мне упало уведомление от закрытого канала, в котором я не состою, но когда-то (часов 10 назад) входил на 10 минут по инвайт-ссылке и вышел.

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

То есть в инфраструктуре ТГ есть баг, из-за которого можно попытаться следить за действиями чата/канала, при этом не состоя в нём. Или же что какое-то ваше сообщение может по ошибке прилететь к тому, кто не должен никогда его получить. По ошибке ТГ, а не вашей.

Ну и ещё это означает, что оконечное шифрование не используется, но это как бы и так очевидно.

В общем, я не одинок. Есть темы на редит, на XDA, в официальном Самсунг Комьюнити об утечке памяти с обновлением до Android 10. Затронуты все популярные модели. Возможно баг в их оболочке.

Такие вот дела. Можете погуглить Samsung Android 10 kernel memory leak. Люди платят свои кровные, чтобы смотреть за тормозами системы. Ну и за тем, что приложения в фоне не живут, их OOM killer убивает.

Баг у Билайна. Может быть не только у них.

У меня симка Москвы и области и ей несколько лет. Относительно недавно отменили роуминг внутри страны и вот я приехал на пару недель в другой регион. Теперь у меня исходящие звонки отмечаются как звонки на скрытые номера, если вызываемый ответил

Обратите внимание на абсурдность:
1. Исходящие звонки
2. В журнале звонков
3. Если только абонент принял вызов

Происходит это и с вызовами на местный Мегафон, и с вызовами московского МТС (МТС — это звонила жена со своего телефона и у неё такая же проблема).

Смотрите скриншот.

Это всё вызовы одного и того же местного Мегафона. Не принятый отцом вызов отображается нормально, а принятые — скрытыми.

Screenshot (Mar 7, 2020 17:05:49)

Стрелка (карточка для транспорта Московской области) на прод пуши кидает так, будто у них трубу прорвало и они руками пытаются удержать поток.

Это не баг, а запланированное поведение, но тем не менее сходу оно может попортить нервы тем, кто погружается в Espresso (как я).

Есть аннотация @Rule. Поля и методы с этой аннотацией выполняются до всех @Before и после всех @After. Поля выполняются до методов. Порядок полей и порядок методов при этом не определён, так что есть ещё RuleChain, но не об этом разговор.

Эталонный пример Правила — это ActivityTestRule. К примеру у меня это СплешАктивити. Я знаю, что она будет запущена и завершена до выполнения метода с аннотацией @Test и завершена после его выполнения. Так что в @After я пишу код, который удаляет данные приложения, будто это первый запуск.

Если выполнять методы @Test отдельно, то всё работает. Но если запустить все методы в классе, то все, кроме первого, завалятся, т.к. запущенная по правилу активити будет не той. Будто бы данные не удалены. Но они удалены!

Это происходит потому что запущенный на выполнение процесс приложения не перезапускается, пока не пройдут все тесты. То есть все @Before, @After — всё работает правильно, но процесс не увидит, что данные очищены, потому что он и не будет читать, т.к. он не перезапускается. Если воткнуть какое-нибудь System.exit(0), то тесты упадёт, т.к. процесс завершился.

Есть костыль, чтобы обойти это. Например, созданное правило для активити — выставить флаг запрета запуска, и запускать его вручную и вручную же завершать. Но если у вас несколько экранов, да ещё есть диалоги, да ещё с анимациями, то это не прокатит.

Более правильно — иметь что-то, что будет следить за процессом, но не будет зависеть от него и будет выполнять методы изолировано, с полным завершением процесса.

Можно написать скрипт, который будет на компе будет исполнять команды по-отдельности. Это вполне себе нормальный подход, я его применял когда-то и, возможно, ещё вернусь к нему. Но лучше (впрочем, одно другому не мешает) использовать оркестратор: https://developer.android.com/training/testing/junit-runner?hl=ru#using-android-test-orchestrator Он будет установлен как ещё одно приложение и берёт на себя то, что вы могли делать своими скриптами.

В документации сказано, что можно чистить данные вот такой инструкцией в гредле: testInstrumentationRunnerArguments clearPackageData: 'true'. Но учтите, что данные будут полностью очищаться перед каждым @Test. Если вам где-то надо чистить, а где-то не надо, то лучше реализуйте очистку вручную. Например, засуньте её в @After. Т.к. оркестратор завершает процесс после каждого теста, то с проблемой не перечитывания данных вы не столкнётесь.