Не так давно была новость, что 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

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

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

Еще к первому посту про плагин в комментарии прилетел фича-реквест от Асхара из канала Полуночные зарисовки

Не прошло и года как я ее зарелизил

Теперь при обращении к (companion) object из Java видны все методы, даже если они не @JvmStatic, а при комплишене заодно подставляется INSTANCE или Companion. Ну или имя companion’а, если вдруг его решили как-то назвать, так тоже можно

Из хороших новостей – если что-то пойдет не так, эту фичу можно отключить. Как и фильтр автокомплита в data-классах. То есть, если плагин вам не понравится, он может вообще ничего не делать

Установить его можно тут

Эту фичу я делал в Kiro – видимо, уже скоро мой плагин отправится в музей довайбкодинговой эры

@loops_everlasting

Пока готовил пост, заметил, что забыл в автокомплите точку с запятой

Кстати, если вдруг хотите еще на кого-нибудь подписаться, есть целая папка с годными каналами: https://t.iss.one/addlist/qbQTFP9Kf0U2ZDUy

Так выглядел вайбкодинг с Kiro

(мем мой)