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

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

В последнее время плотно работаю с новой апишкой Android Gradle Plugin, которую завезли в 7.0.0.
Пока не понятно как делать многие штуки, который можно реализовать на старой апишке, но сейчас не про это. Сегодня хочу рассказать про странный баг на который наткнулся, возможно для кого-то это будет полезно, но сначала немного контекста.

В новом API добавили колбэк androidComponents.finalizeDsl { ... }, в котором можно изменить настройки экстеншена android перед тем как он "заморозится". После того как экстеншен заморозится, значения поменять уже не получится, а если попытаетесь, получите ошибку It is too late to modify X.

Для чего вообще нужен этот колбэк finalizeDsl если всё можно настроить прямо внутри экстеншена android?
В обычной жизни он вам скорее всего не понадобится. finalizeDsl становится необходим если нужно написать плагин, который должен изменять экстеншен android в зависимости от каких-то настроек, которые пользователь задаёт в билд-скрипте.

Простой пример. Хотим сделать плагин, который будет один раз принимать конфиг с compileSdk, minSdk и т.д. и применять его ко всем модулям проекта. В этом случае нам нужно применить настройки к экстеншену android, не в тот момент когда плагин применён к проекту (apply), а чуть позже, после того как пользователь настроит наш плагин.
Вот этот самый момент "чуть позже" как раз и есть колбэк finalizeDsl.
Получится такая последовательность действий:
1. apply plugin com.android.application
2. apply plugin my-best-plugin, в этот момент регистрируем коллбэк finalizeDsl
3. выполняем build-script где пользователь изменил настройки нашего плагина
4. запускается finalizeDsl, используются настройки которые указал пользователь

Теперь про баг.
Если вы вдруг захотели конфигурировать поле compileSdk не из блока android, а из finalizeDsl у вас ничего не получится. finalizeDsl не вызывается, если не указано свойство android.compileSdk. Почему? Не знаю. Обход этого — указать в это поле любое значение, всё равно оно заменится позже в finalizeDsl.

Баг завёл, надеюсь поправят. Там же можно найти пример проблемного билд-скрипта.

#android #gradle #agp #bug

С завтрашнего дня буду вести @mobileunderhood. Заходите почитать :)
Помимо классического "почему я пишу под андроид и как я пришел в IT", буду рассказывать:
- Про свой опыт участия в Open-Source и как влиться в эту движуху
- На чём стоит фокусироваться когда публикуете свою библиотеку
- Про инструменты которые помогают мне в повседневной работе

Кстати, вкидывайте темы в комменты, если вдруг хотите чего-то конкретного. Есть ещё незанятые выходные :)
#анонс

В Gradle 7.4 вышла из статуса превью фича Version Cаtalogs, которая позволяет централизованно объявлять зависимости проекта.
Поправили проблему из-за которой было сложно использовать плагины, объявленные через Version Catalogs.

Проблема заключалась в том, что плагины объявленные через Version Catalogs нельзя было подключить "без указания версии". То есть подобная запись всегда включала в себя версию плагина:

plugins {
    alias(libs.plugins.android)
}

Если вы попробуете подключить плагин с указанием версии в корневом и дочернем проекте, Gradle заругается, что в дочернем проекте версию указывать не нужно потому что плагин уже есть в classpath.
Ну.. Вернее раньше заругался бы, а начиная с 7.4 не будет ругаться если версии одинаковые.

Штош. Осталось дождаться когда в IDEA и Android Studio заработает подсветка и автодополнение зависимостей из Version Catalog'ов.

#gradle

Два месяца назад я перестал писать в этот канал потому что два месяца назад начался [Роскомнадзор] в Украине который по закону РФ нельзя называть войной. В такое время не до саморазвития, не до поиска интересного и изучения чего-то нового. Но теперь, когда стало понятно, что из этой реальности никуда не деться, я решил продолжить писать.

Я создавал канал чтобы делиться "лайвхаками", которые нахожу, писать заметки обо всём интересном с чем сталкиваюсь на работе и в open source. Чтобы делиться с вами и в то же время записывать для себя.
Так и останется. Считаю невозможным превращать канал в трибуну для своих взглядов.

Тем более когда написать два слова "Нет войне" это достаточно дорогое удовольствие.

1-го апреля сходил на подкаст "Сушите вёсла" в первый выпуск DryTalks. Обсудили изменения в Open Source, блокировки и VPN как средство их обхода.
Кстати, там уже и второй выпуск вышел.

Подтверждаю, scrcpy крайне полезная штука. Особенно если разбил экран телефона так, что на нём ничего не видно.

UPD: Вообще если интересно про тулинг, в прошлой реальности у меня была серия твитов про это на mobileunderhood. Может стоит и сюда подобный контент постить?

В последнее время Firebase очень странно себя ведёт и сыпет 403 время от времени при попытке скачать сборки. В какой-то момент всё становиться нормально, но потом снова проблемы.
По наблюдениям QA, через VPN (пробовали США, Турцию, Нидерланды) всё качается нормально.
На блокировку не очень похоже, если сбой, то почему VPN спасает? 👇

Как известно, IDEA 2022.1 не поддерживает AGP версии выше чем 7.0.
Обычно это лечится добавлением такого флажка в gradle.properties:

android.injected.studio.version.check=false

Но с версией AGP 7.1 и выше так сделать не получается из-за того, что в IDEA старая версия android плагина из Arctic Fox, а в Bumblebee (и в AGP 7.1) немного поменялась модель проекта, в частности появился Unified Gradle test runner и это изменение как раз ломает синхронизацию проекта (IDEA не может найти новый enum UNIFIED_TEST_PLATFORM).

Чтобы понять можно ли это как-то полечить, я полез в исходники и оказалось, что ничего лечить уже не надо и в IDEA 2022.2 EAP уже зашит android плагин из Chipmunk (2021.2.1).
Почему-то в блоге в постах про EAP это изменение не упоминается.

Так что теперь снова можно работать в IDEA над андроидными проектами. По крайней мере пока снова не появятся обратно несовместимые изменения в модели проекта.

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

А сегодня пока обновлял каталоги версий наткнулся на kotlinx-coroutines-play-services. И там помимо await есть ещё конвертация в Deferred и обратно.

#kotlin

Коротенькая статья откуда в Unix системах тянется вся эта борода с директориями /bin, /sbin, /usr/bin, /usr/local/bin и т.д.
Если интересно для чего нужны остальные каталоги в корне, можно почитать мануал который открывается по команде man hier (от слова hierarchy).

Есть ещё много подобных похожих, но при этом разных, вещей. Например разница между .bash_profile и .bashrc:
- .bash_profile исполняется при запуске "login shell". Например, при автризации через SSH или в tty
- .bashrc - в остальных случаях при запуске интерактивной оболочки. Например, при открытии терминала или при запуске из другой оболочки по команде bash

Казалось бы зачем эта информация, но это полезно знать чтобы понимать, почему переменные окружения, добавленные в .bash_profile не работают, а в .bashrc работают.

Недавно вышел compose-compiler 1.2.0, а значит пора пересаживать проекты на Kotlin 1.7.0.
Причём не обязательно переводить весь проект на compose 1.2.0-rc03, достаточно обновить только compiler.
Судя по исходному коду compose-compiler 1.2.0 может компилировать и старые версии начиная с compose 1.0.0

#kotlin #compose

В ноябре записался в ранний доступ к Fleet и вот сейчас, когда я про это уже забыл, пришло письмо, что можно его установить и опробовать :)

Запускается и работает быстро, умные функции типа автодополнения и инспекций включает только когда они нужны - если нажать специальную кнопочку. Содержимое панелей слева снизу и справа можно настроить под себя.
В общем, Fleet идеально справляется с задачей текстового редактора с подсветкой синтаксиса..

Полноценно заменить IDEA или AS для больших проектов Flet пока не может. Скорее всего вам будет не хватать Android плагина и других интеграций с используемыми фреймворками.

Мои мечты, что можно будет открыть любой скрипт на python или bash и запустить его одной кнопочкой, к сожалению, пока не сбылись. Во-первых Fleet не поддерживает shebang, во вторых, питоновский скрипт без приседаний запустить не удалось из-за бага. Уверен, эти проблемы поправят в будущем.

На очереди ещё затестить главные фичи:
- возможность подключиться в режиме "териминала" к Fleet'у на удалённой машинке
- режим совместной работы - интересно отличается ли он от Code With Me
#tools #fleet

Как вам новая цветовая схема "New Dark" в IDEA?

#idea

Чем больше узнаю про всяческие оптимизации которые делает компилятор и инструменты типа R8, тем меньше верю в код который пишу.

Был в нашем проекте такой код с рефлексией:
SnackbarHostState::class.java
.declaredFields
.first { it.type == Mutex::class.java }
Я был уверен, что этот код достаточно безопасный и устойчивый к обфускации, т.к. мы не завязываемся на имя поля, а находим его по типу. Поле с типом Mutex в SnackbarHostState единственное, что может пойти не так?
Но всё сломалось после очередного обновления зависимостей и Android Gradle Plugin. Релизные сборки начали падать с ошибкой NoSuchElementException: Array contains no element matching the predicate в месте вызова first.

Первым делом я проверил, что реализация класса не поменялась и поле mutex не пропало — оно на месте, да и если бы оно пропало, падали бы не только релизные сборки.
Тогда заглянул в реализацию функции Mutex() чтобы удостовериться, что возвращаемый тип по прежнему Mutex — тоже всё в порядке.
И вот тут закралось подозрение, что R8 просто заинлайнил вызов функции и напрямую подставил вызов конструктора, сломав тип поля при этом.

Просмотр dex файла показал, что так и есть — у поля mutex теперь тип MutexImpl (который, кстати, internal). Не, ну а почему бы и нет? Сайд-эффектов у Mutex() нет, поле mutex приватное, от изменения типа публичное API не пострадает, так что почему бы не заинлайнить?

Полечил проблему поменяв код внутри first так, чтобы находить любой тип, реализующий интерфейс Mutex:
Mutex::class.java.isAssignableFrom(it.type)

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

#r8

Если загуглить "как переподписать APK", скорее всего наткнётесь на советы типа "удалить из APK папку META-INF, прогнать zipalign и подписать APK заново".
Но если так сделать с Signature Scheme v2, будут проблемки.

При подписи через jarsigner (v1) все изменения действительно вносятся только внутрь META-INF. Достаточно удалить эту папку, чтобы получить свеженький, нетронутый подписями APK. Но в v2 к APK добавляется APK Signing Block, который так просто уже не удалишь.

На самом деле решение простое — вообще ничего не делать. apksigner теперь сам умеет переподписывать APK новой подписью.
А ещё можно воспользоваться моим скриптом (чтобы получить красоту как на скриншоте). Он уже учитывает всяческие тонкости, а заодно умеет подписывать AAB.

#snippet #signing