Текст будет в комментарии

    /**
     * Retrieves default launcher package name
     *
     * @return package name of the default launcher
     */
    public String getLauncherPackageName() {
        Intent intent = new Intent(Intent.ACTION_MAIN);
        intent.addCategory(Intent.CATEGORY_HOME);
        PackageManager pm = mInstrumentation.getContext().getPackageManager();
        ResolveInfo resolveInfo = pm.resolveActivity(intent, PackageManager.MATCH_DEFAULT_ONLY);
        return resolveInfo.activityInfo.packageName;
    }

UiDevice из uiautomator от Google утверждает, что лончером у меня является com.android.settings, а не com.android.launcher3. Лан, напишу свою определялку.

Поисследовал поведение и похоже дело такое:
- https://issuetracker.google.com/issues/178965163
- воспроизводится на Android 11 и новее. Стреляет из-за фичи видимости пакетов. Ну знаете, нужно в манифесе прописать <queries> либо дать разрешение на получение всех приложений
- настройки действительно являются лаунчером. Но когда пользователь таки разблокирует устройство, они передают управление лаунчеру по умолчанию

Решений этой проблемы два с половиной варианта:
1. Написать свой детект лаунчера. Я не проверял, но чел утверждает, что работает: https://github.com/adil-hussain-84/UiAutomatorExperiments. Это не мой путь. Выше я уже писал, что не хочу подменять поведение фреймворков без крайней нужды
2. В Манифесте включить ожидаемые ланчеры в видимость. В моём случае:

    <queries>
        <package android:name="com.android.launcher3"/>
    </queries>

2.1. В Манифесте объявить разрешение android.permission.QUERY_ALL_PACKAGES, которое позволит видеть все приложения. Возможно вам будет удобнее этот вариант

Появилась задачка сделать автотест Android параметризируемым. Если быть точным, то нужно уметь читать экраны Google Play Store сотни разных приложений. Можно сделать сотни тестов с именами пакетов, но лучше сделать метод @Test всего один, но чтобы он мог принимать пакеты.

Как вы решали подобные задачи? Что говорит Гугл? Я просто и не искал, т.к. уже делал подобное и просто повторил то, что делал давно.

Суть такова:

    @Test
    fun demoMethod() {
        val arguments = InstrumentationRegistry.getArguments()
        Log.d("MyTestPackage", "first=${arguments.getString("first")}\n" +
            "second=${arguments.getString("second")}\n" +
            "third=${arguments.getString("third")}")

Запускается так: adb shell am instrument -w -e first "вот\ это\ я\ понимаю\ строка" -e second 100500 -e third 3.1415 -e class xyz.myachin.letsappsbeupdated.playstore.PlayStoreUpdateApps#updatePackage xyz.myachin.letsappsbeupdated.test/androidx.test.runner.AndroidJUnitRunner

Ну и получаем

2023-05-30 21:23:14.185 28039-28058 MyTestPackage           xyz.myachin.letsappsbeupdated        D  first=вот это я понимаю строка
                                                                                                    second=100500
                                                                                                    third=3.1415

везде getString(), потому что аргументы приходят строкой. Можно написать обёртку с приведением к нужным типам, но это оверхед.

Подписался, чтобы оставить единственный комментарий. Всё, отписаться больше нельзя. ВК это сделали или ещё со времён Яндекса баг - не знаю: воспользовался дзеном впервые в жизни. И сразу вляпался

Написал инструмент для вытягивания приложений из разных сторов на Android. В случае вот такого сообщения бросаю себе исключение "у нас нет аусвайса для этого пакета"

xyz.myachin.letsappsbeupdated.exceptions.StoreException: We have not an ausweis for com.bmw.ConnectedRide.na

Потому что так себя и чувствую

Только что пришёл ответ. Проблема исправлена, обновитесь на последнюю версию. Ну, всё хорошо, что хорошо заканчивается.

Задача утилиты 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Мб)