Мир Пэй просто перманентно находится в ANR. Я отправил им 60 последних отчётов. Посмотрите на частоту:

- Вот вам багрепорт
- А где паспорт и мазок?

https://text.tchncs.de/umnik/eto-prosto-podbivka-spiska-izmenenii-s-poiasneniiami-chtoby-ne-skakat-po-stat-ia

Подбил в одном месте, какие изменения в Android 14 будут для нас — разработчиков и тестировщиков.

Попробовал новую блогоплатформу, но позже скопирую этот текст на привычный blogspot. Было бы классно найти платформу для блогов, именно длинных, с картинками и всё такое, но быстрых. И не тех, которые завязаны на конкретные сервисы типа Телеги.

В общем, с блогспота надо валить, но куда. Вот, трогаю пока writefreely. Он и маркдаун поддерживает, и является частью федивёрса

https://myachinqa.blogspot.com/2023/03/android-14.html

Та же самая статья, просто на блогспоте. Могут вылезти старые, уже исправленные, опечатки, т.к. я запутался в версиях и мог перенести не ту. Ну, опечатки на суть не влияют.

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

То, что основная масса пользователей будет делать это на автомате для калькулятора оценки роли не играет, так что норм. Многопользовательские системы также не рассматриваю, т.к., будем честны, более одной учётной записи Windows — это прям лютая редкость. Но нужно понимать, что если атакующий — ваша "половинка" или кто-то, кому вы (зря) доверяете, то защиты сейчас нет. Он просто запустит заразу _в своём сеансе_ и в нём же поднимет заразе привилегии, предоставив возможность читать память процессов _в вашем_ сеансе. Но это опускаем.

В общем, будем надеяться, проблему исправят.

Дополнительно — скоро запишу видос про уязвимость в Android, которую исправили. Сейчас период релизов, просто не до этого. Но я не забыл :) И да, денег всё ещё не заплатили. Висят в статусе PENDING.

Обещанная статья про уязвимость в Android, которую нашла наша команда. Напомню, что сводилась она к тому, что WhatsApp получал доступ к микрофону так, что Android этого не видел и никак не сигнализировал: не сохранялось в истории доступа, не появлялся соответствующий индикатор.

Текст один и тот же, выбирайте, в каком форматировании вам удобнее читать. Ну и первая весит поменьше. Ссылка на PoC в статье есть.

https://text.tchncs.de/umnik/obkhod-rezhima-mode_ignored-v-app-op

https://myachinqa.blogspot.com/2023/03/modeignored-app-op.html

Если вы хотите сообщить о проблеме в "Мой Офис" (входит в реестр отечественного ПО), то у вас затребуют персданные. Читаем соглашение о них:

2. Цели сбора и обработки персональных данных

- направление подписчикам и пользователям Сайтов сообщений информационного и рекламного характера посредством электронных почтовых сообщений и смс-сообщений с соблюдением требований действующего законодательства Российской Федерации;

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

Вообще удивительное дело. Наши разработчики ПО выполняют 152 ФЗ спустя рукава и используя максимум лазеек, чтобы положить на него болт. При этом исполнять требования GDPR бегут, роняя тапки. Выглядит так, что производителям ПО положить хрен на сограждан, но вот эльфы из Европы достойны самого лучшего

Кто-то, простите не помню кто, но точно был подписан, спрашивал про стажировку. У меня её нет, но вот мои бывшие коллеги делают: https://safeboard.kaspersky.ru/ Оплачиваемая!

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

И нет, это не реклама. :) Просто у меня, что называется, перед глазами опыт, когда студент из сейфборда стал манагером в ЛК. Привет тебе, кстати, если ты это читаешь.

https://music.yandex.ru/album/18910064/track/110185672

- У нас была платёжная форма, на которую было написано 9 тыс. строк тестов и ни один из них не проверял чего-то нужного
- Как так?
- Это тесты, ну там, на уровне, где вообще всё замокано. И условие такое: if (true) { return true }. И так 9 тысяч строк кода

СЯУ, что клиенты ДОЛЖНЫ (MUST) сваливать коды возврата в их дженерик варианты, когда не знают реального кода. HTTP коды, в смысле.

Суть в том, что списки кодов возврата расширяемы (ну, это не новость) и, если клиент не знает конкретного кода, он MUST обработать код как x00. То есть 204 → 200, 409 → 400 и прочее.

И тут у меня флешбек из прошлого, когда в антивирусе был switch на коды возврата и dafault значение было "перезапросить снова". И как антивирусы стали класть сервак на лопатки, когда тот отвечал кодом, на который не было case.

Ухудшилась стабильность автотестов на Espresso. Стал разбираться, в чём дело.

У меня есть тест, который следит за таймером на экране. Так как я стараюсь не трогать код самого приложения (лезть в код, который написан много лет назад - себе дороже), то использовал банальный способ: делаю ViewAssertion на нужный мне текст и, если получаю исключение о несовпадении текста, повторяю попытку. Ну а что поделать, приходится так.

Это работало прекрасно несколько лет. И недавно сломалось. Каждый раз ассершен не обнаруживает нужный счётчик, пролетает мимо. Стал отлаживаться и увидел, что эспрессо просто замирает на 5 секунд после каждого опроса!

Оказалось, что поведение Espresso изменили в 3.5.0: https://developer.android.com/jetpack/androidx/releases/test#espresso-3.5.0

Espresso's DefaultFailureHandler now saves a screenshot on test failures to TestStorage

И вот если эспрессо не смог снять скриншот, он замирает на 5 секунд. Но хотя бы сообщает об этом в лог: java.util.concurrent.TimeoutException: Waited 5 seconds (plus 1063571 nanoseconds delay) for androidx.concurrent.futures.ResolvableFuture

Эта проблема не только у меня, вот другой человек жалуется: https://github.com/android/android-test/issues/1584

Гугл сжалился и сделал "фикс" https://github.com/android/android-test/commit/44b2b456d3052f6114ac3e3b5d2676e6f8885e37 На самом деле не фикс, а просто теперь я обязан создать свой FailureHandler и выставить отключение снятия скриншота.

Фикс доступен только в альфе: https://developer.android.com/jetpack/androidx/releases/test#espresso-3.6.0-alpha01: Allow customizing espresso's default failure handler to disable screenshots on failures

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

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

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

    /**
     * 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
Удаление приложений, которые были установлены в текущей сессии