The creation of this channel was inspired by @themishkun. You can subscribe to him

Наконец добрался до канала, зато с новостями

На досуге сделал плагин для Intellij, решил написать об этом статью, и ее опубликовали в ProAndroidDev! Claps or any feedback appreciated, а сам плагин можно посмотреть тут

В ближайшее время постараюсь сделать перевод для хабра

а вот, кстати, и перевод

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

на хабре гифка локализована; оригинал – в первом комментарии

Kotlin function types

ответил в комментариях в Android Good Reads, но решил и тут написать, вдруг кому-то будет интересно

допустим, у нас есть такой Java-класс

public class SomeJavaClass {

    interface Listener {
        void onEvent(String event);
    }

    private HashSet<Listener> listeners = new HashSet<>();

    void addListener(Listener listener) {
        listeners.add(listener);
    }

    void removeListener(Listener listener) {
        listeners.remove(listener);
    }
}

и такой Kotlin-класс

class SomeKotlinClass {

    private val eventListenerLambda = { eventId: String ->
        println(eventId)
    }

    fun testLambdas(someJavaClass: SomeJavaClass) {
        someJavaClass.addListener(eventListenerLambda)

        someJavaClass.removeListener(eventListenerLambda)
    }
}

чтобы передать лямбду типа (String) -> Unit в качестве параметра типа Listener, компилятор либо использует method reference, либо, когда Java 6, заворачивает в адаптер, и в обоих случаях инстанс итогового Listener каждый раз получается разный

public final class SomeKotlinClass {
   @NotNull
   private final Function1 eventListenerLambda = SomeKotlinClass::eventListenerLambda$lambda$0;
   public static final int $stable;

   public final void testLambdas(@NotNull SomeJavaClass someJavaClass) {
      Intrinsics.checkNotNullParameter(someJavaClass, "someJavaClass");
      Function1 var2 = this.eventListenerLambda;
      someJavaClass.addListener(SomeKotlinClass::testLambdas$lambda$1);
      var2 = this.eventListenerLambda;
      someJavaClass.removeListener(SomeKotlinClass::testLambdas$lambda$2);
   }

   private static final Unit eventListenerLambda$lambda$0(String eventId) {
      Intrinsics.checkNotNullParameter(eventId, "eventId");
      System.out.println(eventId);
      return Unit.INSTANCE;
   }

   private static final void testLambdas$lambda$1(Function1 $tmp0, String event) {
      $tmp0.invoke(event);
   }

   private static final void testLambdas$lambda$2(Function1 $tmp0, String event) {
      $tmp0.invoke(event);
   }
}

и если запустить, можно увидеть, что после выполнения someJavaClass.removeListener(eventListenerLambda) содержимое listeners не изменится

напишите в комменты, кому это было очевидно!

LinkageError

На днях готовил к релизу наш SDK для Unity. И всё должно было быть просто, потому что это обертка над нативными, самое сложное позади

А на нативном SDK для Android у нас есть UI-фича, которая сделана на Compose

И вот при взаимодействии с ней в Unity-проекте всё крэшилось с java.lang.NoClassDefFoundError, в рантайме почему-то не нашлось класса, который был при компиляции. Это частный случай java.lang.LinkageError – обычно такие ситуации возникают, когда dependencyA уже ранее была скомпилирована с dependencyB, но в рантайме оказалась другая версия dependencyB, с несовместимым API, либо её вовсе нет. А так как всё уже было скомпилировано ранее, ошибка происходит в рантайме

На нативном SDK при этом всё хорошо; другие пакеты в Unity не привносят конфликтующие androidx-зависимости

Если кто-то догадался, что произошло, пишите в комменты

Разгадка

Дело в том, что гугл не отстает и тоже переводит свои библиотеки на KMP – таким образом, у артефакта есть какой-то общий id (например, lifecycle-viewmodel), а для конкретного таргета уже выбирается зависимость с соответствующим суффиксом. В итоге некоторые транзитивные зависимости зарезолвились как-то так:

+--- androidx.compose.material3:material3-desktop:{strictly 1.3.0} -> 1.3.0 (c)
+--- androidx.lifecycle:lifecycle-viewmodel-compose-desktop:{strictly 2.8.0} -> 2.8.0 (c)
+--- androidx.compose.ui:ui-jvmstubs:{strictly 1.7.2} -> 1.7.2 (c)

Только суффикс должен был быть -android.

Напишите, кстати, в комменты, кто сталкивался с таким. Кажется, что это не очень тривиально – практически все пишут на котлине, и когда мы подключаем Kotlin Gradle plugin в модуль, зависимости резолвятся с ожидаемым суффиксом:

+--- androidx.compose.material3:material3-android:{strictly 1.3.0} -> 1.3.0 (c)
+--- androidx.lifecycle:lifecycle-viewmodel-compose-android:{strictly 2.8.3} -> 2.8.3 (c)
+--- androidx.compose.ui:ui-android:{strictly 1.7.2} -> 1.7.2 (c)

Бридж, который связывает слой нативного андроида и Unity, был написан на Java; Kotlin-плагина в проекте не было вообще.

Ну а дальше всё просто: каких-то сущностей не оказалось в -desktop/-jvmstubs–артефактах –> в рантайме был крэш с LinkageError.

P.S. Начиная с AGP 8.4 такой проблемы больше нет. На проекте был 8.3

кто бы мог подумать, что картинку спойлерить можно, а monospace и code block – нельзя

public final override

Помимо разработки библиотек, есть еще один кейс, где эсплицитный public несет дополнительную смысловую нагрузку

abstract class Animal {

    protected abstract fun say(): String
}

abstract class Fox : Animal() {

    public override fun say(): String {
        return "Ring-ding-ding-ding-dingeringeding!"
    }
}

class ArcticFox : Fox() {

    // тут public уже не нужен
    override fun say(): String {
        return "Wa-pa-pa-pa-pa-pa-pow!"
    }
}

class FennecFox : Fox() {

    // тут тоже
    override fun say(): String {
        return "Chacha-chacha-chacha-chow!"
    }
}

С точки зрения синтаксиса котлин такое позволяет, и тулинг не подсвечивает его как redundant

А еще в котлине есть ключевое слово final

Концептуально это очень похоже на предыдущий кейс, ибо и public, и final здесь выполняют одну и ту же функцию – нивелируют предыдущую эксплицитную декларацию: public можно использовать для того, чтобы перекрыть protected / internal, а final – для open / abstract

open class RedFox : Fox() {

    final override fun say(): String {
        return "A-hee-ahee ha-hee!"
    }
}

class EuropeanRedFox : RedFox() {

    // ошибка – “’say' in 'RedFox' is final and cannot be overridden”
    override fun say(): String {
        return "A-oo-oo-oo-ooo! Woo-oo-oo-ooo!"
    }
}

@loops_everlasting

Не так давно была новость, что Android 16 будет игнорировать* screenOrientation и прочие хаки, чтобы дизайнеры могли после обеда уходить домой. Но только при targetSdk = 36

Самое время вспомнить, что это за три магические константы, которые так любят на собесах

compileSdk

Так как наше приложение взаимодействует в том числе с api андроида, нужно с ним как-то скомпилироваться

Для этого у каждой версии Android SDK есть свой файлик android.jar, в котором лежит только публичный api, без имплементаций (если вы натыкались на throw new RuntimeException("Stub!”), это как раз оно). Но для того, чтобы скомпилироваться, нам этого достаточно

Таким образом, если у нас compileSdk = 35, нам недоступны api, которые появились в новой бете андроида (36) – в нашем android.jar их просто нет

Но если очень хочется, можно ли поменять цифру прямо сейчас и ничего не сломать? Да, но об этом дальше**

minSdk

Я там уже заспойлерил, что compileSdk поднимать безопасно, – давайте так и сделаем!

Теперь мы можем использовать новые api, но если запустить этот код на Vanilla Ice Cream, будет крэш в рантайме с LinkageError. Поэтому тулинг злобно подчеркивает такие места, заставляя нас делать дополнительные проверки

Чтобы не добавлять их везде, где андроид зачем-то эволюционировал, как раз нужен minSdk. Какая разница, что метод доступен только в 16 api, когда у нас поддержка начинается с 21?

targetSdk

Тут самое интересное

Андроид регулярно эволюционирует, а иногда даже ломает парадигмы. Так, в версии 23 выяснилось, что получать все пермишены при установке это не дело – нужно дать пользователю право отказаться от прослушки или от доступа к списку друзей контактов

Но в сторах уже есть миллионы приложений, которые об этом ничего не знают, и шквал единиц в Google Play это вопрос времени

Помните, я выше говорил, что повышать compileSdk безопасно? Так вот, всё дело в targetSdk

Все эти приложения не сломаются только потому, что им можно играть по старым правилам. Если targetSdk = 22, то пермишены выдаются автоматически (и были даже кое-какие известные приложения, которые этим пользовались)

Как это работает?

По сути это такие же проверки, которые мы добавляем, чтобы ничего не сломать на более старых версиях, но на этот раз уже со стороны самого андроида:

/**
 * Return true if we are in RTL compatibility mode (either before Jelly Bean MR1 or
 * RTL not supported)
 */
private boolean isRtlCompatibilityMode() {
    final int targetSdkVersion = getContext().getApplicationInfo().targetSdkVersion;
    return targetSdkVersion < Build.VERSION_CODES.JELLY_BEAN_MR1 || !hasRtlSupport();
}

Или вот

На первый взгляд низкий таргет выглядит как хак, чтобы обходить ограничения гугла. Но нет – в какой-то момент лавочку прикрыли, и теперь гугл каждый год инкрементит минимальный targetSdk, с которым можно опубликовать приложение

В этом году будет 35

@loops_everlasting

*худ. преувел.; исключения и прочие нюансы тут

**был любопытный кейс, когда всё сломалось, но по другой причине