Задача утилиты fastboot в Android SDK - прошивать образы на телефон. Google сломал это: https://issuetracker.google.com/issues/284327750 при попытке зашить образ 34-ой версией фастбута получаем fastboot: error: ANDROID_PRODUCT_OUT not set. ОС не важна.

Варианты обхода проблемы до выпуска исправления:
1. Откатиться на 33
2. export ANDROID_PRODUCT_OUT=$ANDROID_HOME/platform-tools перед прошивкой. Переменная окружения ANDROID_HOME задана, надеюсь?

У утилиты одна задача. И ту сломали. Google можно сделать слоган: "ломаем то, что не закрыли"

Как же меня бесит вот эта фича STF: https://github.com/DeviceFarmer/stf/blob/620be9ba21d29151781c56469539e7f8226e3379/lib/units/device/plugins/cleanup.js#L40
Удаление приложений, которые были установлены в текущей сессии

Коллеги-тестировщики, важный вопрос. Есть ли у вас какая-то готовый список, который можно взять за основу, чтобы правильно ранжировать тестировщиков по навыкам, от джуна до бесконечности?

Или, тоже нормальный вариант, скажите, что, на ваш взгляд, должен уметь тестировщик на том или ином грейде.

Строго говоря, это не баг, но мне не нравится это поведение. Приложения с разрешением ТОЛЬКО READ_CALL_LOG могут частично получить также и телефонную книгу, хоть и окольным путём.

В чём, собственно, суть. Вот есть разрешение для чтения истории звонков: https://developer.android.com/reference/android/Manifest.permission#READ_CALL_LOG И оно предназначено именно для истории звонков. Ничего не сказано о том, что можно получить доступ к записной книге. И, формально, доступа действительно не будет.

Таким образом я ожидал, что буду видеть только информацию о звонках, без возможности понять, чей именно этот входящий или исходящий номер. Ну номер и номер.

Однако самой БД в истории звонков есть вот такое поле: https://developer.android.com/reference/android/provider/CallLog.Calls#CACHED_NAME. И здесь реально написаны имена из записной книги. То есть доступа к контактам у меня нет, но имя и номер телефона я связать могу, т.к. вижу и то, и другое.

При чём это звонилка МОЖЕТ заполнять это поле для кеширования. А может и не заполнять, но тогда ей придётся постоянно дёргать ещё и записную книгу, чтобы отобразить имя вместо телефона. Вот Google Dialer из Pixel телефонов это поле заполняет.

В итоге с одной стороны это ускоряет отрисовку истории звонков, т.к. не требуется обращаться к ещё одной базе (к контактам), а с другой — любое приложение БЕЗ доступа к записной книге, но с доступом к истории звонков, хотя бы частично, но может восстановить связь "номер" <-> "имя".

Вроде звучит не так, чтобы страшно. Казалось бы, если есть доступ к истории звонков, то уже плохо. Но с другой стороны:
1. Это поведение не ожидается. Пользователь одобрил только историю звонков, но не доступ к контактам
2. Шпионское приложение может сидеть и ждать нужного звонка, не создавая никакой сетевой активности, чтобы лишний раз себя не выдавать. А когда "Вася Иванов" таки появится вдруг в логе звонков, сразу отправить этот номер телефона кому следует и дальше уже пофигу, пусть шпиона обнаруживают — своё дело он сделал

Итак, в начале августа мне написали, что проблема исправлена и фикс уже выложен на сайте. Стоило с февраля отнекиваться и прикидываться, что проблемы нет? CVE, кстати, не оформляли :) То есть в статистике обнаруженных уязвимостей продукта эта фигурировать не будет. Типа, не было её никогда.

И забавно вот ещё что. В своём оригинальном письме я указывал, что эта же проблема есть у KeePass и KeePassXC. Но у них есть инструменты уменьшения урона (например, указание ключевых файлов). К тому же у них самих на сайтах написано, что такое поведение в целом ожидается. И потому я не стал писать авторам keepass о проблеме, ведь они информировали о ней прям на сайте. ОДНАКО. Не смотря на то, что тот же KeePass имеет механизм снижения угрозы и вообще предупреждает, что угроза в целом существует, потому что это дотнет, он ВСЁ РАВНО ПРИНЯЛ РЕПОРТ ОБ ЭТОМ от другого человека: https://sourceforge.net/p/keepass/discussion/329220/thread/f3438e6283/

Как видите, репорт в keepass был в мае, тогда как я не стал репортить (оказалось, что зря) в феврале. Описание угрозы соотвествует моему — восстановление пароля из дампа. И эту уязвимость оценили на 7.5: https://nvd.nist.gov/vuln/detail/CVE-2023-32784 Тогда как мой репорт Касперскому (все уже поняли, что речь про Касперский Пассворд Менеджер) оценили на 4.2, т.к. доступ к дампу требует админских прав.

Одинаковые уязвимости в СПО и закрытом коммерческом ПО, вызванные одной проблемой - дотнетом. Но подходы разные. У СПО:
- репорт первого мая
- разработчик 2-го мая отписывается в стиле "понял-принял, ща займусь"
- 7-го мая разработчик предоставляет сборку на проверку. Мало того, он объясняет, в чём проблема и какие действия он предпринял
- 8-го мая репортер подтверждает, что проблема устранена
- 9-го мая разработчик сообщает, что проблема будет устранена в ближайшем релизе в течение 2х месяцев (напоминаю про 3 месяца на устранение уязвимости - это норма)
- 3-го июня разработчик публикует релиз с устранением этой и двух других уязвимостей.

Итого:
- Признание проблемы: 1 день
- Публикация прототипа фикса для оценки ресёчером: 7 дней
- Публикация исправления: ~36 дней

А теперь платное ПО с закрытым исходным кодом:
- Репорт: 3-е февраля. При этом в репорте было приложено видео, а воспроизводилось не махинациями с мемори дампом, а просто утилитой арт мани. То есть для воспроизведения нужно просто мышкой потыкать
- Понял-принял: 6 февраля
- Мой вопрос: "есть ли продвижение?": 14 февраля
- Ответ, что не удалось воспроизвести: 15 февраля. Там же написано, что похожее исправили в 2019. То, что есть видео и это заведомо последняя сборка роли не сыграли
- Моё охреневание от ответа: 15 февраля
- "Попробуем воспроизвести повторно": 17 февраля
- "Дмитрий, привет, воспроизвели, даём оценку 4.2" https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:H/I:N/A:N : 15 марта
- Небольшая переписка, где я сказал, что ладно, 4.2 так 4.2. Главное исправьте
- "Будем держать вас в курсе": 28 марта
- "Спасибо за ожидание. Проблема устранена. Сборка доступна для скачивания, апдейт летит к клиентам": 3 августа

Я даже считать дни не буду, вы сами даты видите.

Отдельно меня позабавил вопрос в письме, буду ли я публиковать информацию по этой проблеме. Я честно не знаю, какое это отношение имеет к устранению или не устранению уязвимости и спросил в ответ, а на что это влияет? Спросил тогда же, 3-го августа. Сейчас 18 и мне не ответили. Ну, ждать ещё полгода на ответ не хочется, потому пишу тут. Здесь меньше 200 человек, так что особо ситуация не разлетится. Но выводы делать нужно.

В следующем сообщении прицеплю видео с воспроизведением. Сможете проверить сами, понадобится только Шинда и АртМани. Также в письме от 3-го августа указано, что при использовании буфера обмена очистка произойдёт через 2 минуты. Для сравнения, у KeePassXC:
- 10 секунд на буфер обмена
- есть механизм вообще не использовать буфер обмена. В этом сценарии кипасс будет посылать события ввода с клавиатуры, так что читать буфер обмена будет бесполезно - там нет пароля

Прошу прощения за затянутость видео. Немного нервничал и иногда делал лишние действия. Суть в том, что показываю, что пароль не уходит после сворачивания и даже после блокировки базы. А в случае смены пароля переиспользуются те же участки памяти, что позволило в реальном времени обнаружить изменение мастер пароля. Всё же как хотите, а .Net в целом не подходит для такого https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md Но вот автор KeePass показал, что даже проблемы .Net можно обойти. Интересно, Касперские выкатили фикс после KeePass, который тоже на дотнете. Совпадение?

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

- 192.0.2.0/24 (TEST-NET-1)
- 198.51.100.0/24 (TEST-NET-2)
- 203.0.113.0/24 (TEST-NET-3)

Это буквально адреса, зарезервированные для того, чтобы их использовали в документациях. Их маршрутизация запрещена.

Подробнее: https://www.rfc-editor.org/rfc/rfc5737.html

Подобное есть и для IPv6: https://www.rfc-editor.org/rfc/rfc3849 Конкретно рекомендуется использовать 2001:DB8::/32. И желательно использовать именно этот диапазон, а не, к примеру, задепрекейченный https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml 0200::/7. Потому что на 0200::/7, который как бы никто не должен использовать ни для чего, сидит сеть Yggdrasil. И это было осознанное решение авторов: https://yggdrasil-network.github.io/faq.html

Домены описаны в https://www.rfc-editor.org/rfc/rfc2606. Там вы встретите и example.com, и .invalid.

Сейчас на Мобиусе был технический доклад, который был на удивление интересным. Но всю дорогу в голове была мысль: "в этом сценарии подошли бы плейлисты, это просто очевидно и на поверхности".

В конце докладчик говорит: "Вообще в этом сценарии Гугл рекомендует использовать плейлисты. Мы не пробовали, но звучит очень перспективно".

То есть вы проделали кучу вещей, тестировали самые разные подходы, кроме того, который просто самый очевидный? И даже когда вам прямым текстом сказали, что правильно так, вы это ещё не проверили?

Да что с вами не так?! Ваш подход к разработке выглядит как та картинка "рандомная херня вперёд".

Если сто тысяч обезьян будут тыкать в клавиши печатной машинки, он случайно могут написать произведения Шекспира. А вы, случайно, попробуете то, что очевидно и рекомендовано.

Страшная новость: троян Хамелеон может обходить андроидную биометрию. А я сижу, такой, и не могу предположить даже, как это можно сделать. Срочно полез читать: https://www.threatfabric.com/blogs/android-banking-trojan-chameleon-is-back-in-action?utm_content=276256774&utm_medium=social&utm_source=linkedin&hss_channel=lcp-28590268

И знаете как? Да никак. Троян, используя Accessibility API нажимает кнопку use pin на экране биометрии. Потому что не может его пройти и принудительно сваливает на другой тип. Ну а то, что если у трояна есть доступ к accessibility api, то можно сушить вёсла - это вообще не новость.

Итого мы имеем просто ЕЩЁ ОДНОГО трояна, использующего тоже, что и примерно несколько сотен тысяч (миллионов?) других.

Димоооооооонд! https://laime-info.ru/catalog/hard-cheeses/parmezan-gold-40-srokom-sozrevaniya-12-mesyaczev

Официальный сайт, как я понимаю.

Отдельно обратите внимание на URL. Покликайте по стрелкам и следите за адресом.

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

Дважды это для вас, если вы ограничиваете длину пароля сверху.

https://text.tchncs.de/umnik/o-paroliakh-i-parol-nykh-frazakh для любителей федивёрса и лёгких страниц (страница весит меньше 400кб)

https://myachinqa.blogspot.com/2024/01/blog-post.html для любителей блогспота (страница весит почти 4Мб)

Впрочем, ничего нового

Прочитал историю успеха одного юноши, который в 19 устроился в фирму (важно - крупная фирма на несколько тысяч сотрудников, а не стартап), а в 21 он уже синьёр.

И вспомнил вот тот вопрос, который процитировал.

Лично для себя за это время я определил такое описание синьёра.

Это сотрудник, который может заменить _любого_ другого человека в команде (имеется в виду в его профильной области, конечно: в нашем случае тестировщик заменяет тестировщика) практически мгновенно. Его не нужно будет обучать - он сразу готов.
При необходимости, этот синьёр в одиночку может заменить ВСЕХ ДРУГИХ членов команды (для небольших команд, на 3-5 тестировщиков) одновременно и никто не заметит, что все остальные исчезли. Сам синьёр, конечно, начнёт лысеть, у него будет дёргаться глаз и трястись руки и так лучше не издеваться над людьми, но такое возможно.

Без проблем, буквально за пару дней, синьёр влетит в любой другой смежный проект и сохранит все описанные выше фичи. Через пару дней он будет ориентироваться так, будто давно тут работает.

Синьёр может поменять направление проекта за пару недель и снова сохранит все описанные выше фичи. То есть сейчас он в мобилочках, а завтра его закинули в веб (или наоборот) и вот он уже в новом направлении всё тот же синьёр и может заменить всех тестировщиков разом в одиночку.

Чтобы без проблем совершать такие переходы, нужно накопить достаточно немалый багаж знаний и закрепить его опытом. Ты можешь быть очень хорош в своей области и за 2 года набрать отличный опыт. Но всё ещё в пределах своей области. А это, на мой взгляд, не синьёр.

В UiAtomator 2.3 исправили несколько проблем, из-за которых я и начал писать свой фреймворк автотестов. Кажется, скоро смогу отказаться от него (ура!).

Изменений от 2.2 много, вот только те, которые мне важны, потому что у меня были свои реализации, а теперь можно будет использовать гугловые:

- Поддержали отправку события нажатий нескольких кнопок. Я использовал это в первую очередь для снятия скриншотов ПОЛЬЗОВАТЕЛЬСКИМ способом.

- Теперь правильно будят устройство - через отправку кей эвентов. Если вам приходится писать автотесты на вот тех офигенных телефонах, где на кнопку Power навесили вызов ассистента, вы меня поймёте

- Уменьшили интервал полинга в 10 раз. Надо сказать, радикально. Я уменьшал в 5 раз

- Поддержали матчинг многострочных текстов и описаний https://android-review.googlesource.com/c/platform/frameworks/support/+/2283416

- Наконец вытянули UiDevice#executeShellCommand наружу

- Исправлен NPE для UiDevice#dumpWindowHierarchy

- Для UiObject2#scrollUntil добавили retry

- Уменьшили скорость скроллинга. Надеюсь, уменьшили правильно. Потому что мне приходилось опытным путём подбирать steps у скрола, чтобы всё работало нормально

Остальное либо я не использовал, либо работа меня устраивала. Например, поддержку второго экрана ни разу не использовал, а это одна из фич релиза

Написал статью о том, что в RuStore лежит настоящий, но неправильный Signal. И что RuStore имеет прям детскую болезнь: он не понимает архитектуру процессора, на котором работает.

Лёгкая версия статьи (в килобайтах, в смысле): https://text.tchncs.de/umnik/rustore-i-podderzhka-raznykh-arkhitektur

Она же, но на блогспоте: https://myachinqa.blogspot.com/2024/03/rustore.html

Вакансию мечты нашёл.

Требования:
- Релевантные для задач проекта
- Опыт в тестировании от 5 лет