Все мы (разработчики Android-приложений), не так давно получили письмо вида:

И вроде бы ничего удивительного, время от времени Google просит нас повысить Target Api и в большинстве случаев все решается обновлением 1-2 строк в build.gradle чем-то вроде:"compileSdk 35"
"targetSdk 35"
Однако в моем случае удовлетворить требование Google так просто не получится, уверен я в этой проблеме не один, часики тикают, до конца месяца осталось не так уж много времени. С учетом того, что Google дает нам время — до конца месяца. В настройках Play Concole присутствует возможность попросить «отсрочку», но тем не менее...
И так, при условии, что мы используем +‑ современный Android Gradle Plugin, версию Kotlin и все наши библиотечные зависимости в актуальном относительно свежем состоянии, проблем бы не возникло, мы все это дело обновили бы и все у нас было бы хорошо.
Вот‑только, что делать если проект «морально устал», используется какой‑нибудь AGP версии 7.4.2, древняя версия Kotlin, какие‑то сомнительные библиотеки возможность обновления которых вызывает сомнения. Более того, обновление всего вышеперечисленного потребует и правок в реализации тех или иных фичей, ведь какие‑то подходы уже просто deprecated. При всем при этом проект просто огромный с кучей модулей. А времени заказчик(бизнес) выделять на это дело не хочет, более того и оценить масштаб работ весьма проблематично, ведь «править и фиксить» приходится поэтапно, пока все не поправишь оценить масштаб работ попросту невозможно.
Мне не повезло максимально, на мои плечи (не на команду), упала такого рода задача, и 3 сильно древних многомодульных проекта с разным стеком и разным набором всевозможных библиотек и зависимостей.
Android SDK Update Assistant не позволял все «красиво обновить» пришлось все это делать ручками. Таким путем я и пошел, однако потратив несколько дней на «переписывание кода», подбор подходящих библиотек на замену тем, что канули в лету, обновление того, что можно обновить. Процесс затягивался на неопределенное время, а потому я начал поиски альтернативных решений.
Первый вариант, который мне показался простым и рабочим это оставить все как есть, «прибить гвоздями»"compileSdk 35"
"targetSdk 35"
и добавить в gradle.properties:android.aapt2Version=8.6.1-11315950
P. S. нашел такой «лайфхак» на одном из гугловых форумов.
Проверил все на эмуляторах и казалось бы вот оно счастье, однако не совсем)
Несмотря на то, что ревью в «Google Play Console» мы прошли успешно и протестировали работоспособность приложения на эмуляторе и нескольких реальных устройствах, всплыла проблема: На Android 15, на телефонах Samsung (в частности S22+, а может и еще на каких) приложение крашилось на старте, с ошибками как на скриншоте ниже:

При всем при этом на всех остальных версиях Android включая 16 проблем с запуском не обнаружилось. Единственная проблема, которую мы обнаружили на устройствах с версией 16 — это то, что немного «поплыла верстка» на отдельных экранах, но это «лечится» проверками вроде:if (
android.os.Build
.VERSION.SDK_INT >
android.os.Build
.VERSION_CODES.UPSIDE_DOWN_CAKE) {
//какие-нибудь правки по отступами
}
Иными словами проблемы были со списками и методом.first(), можно было бы переписать где это возможно на «.get(0)», но нам доподленно неизвестно все ли это проблемы или может всплыть что‑то еще. Потому было принято не менее радикальное решение:"compileSdk 34"
"targetSdk 35"
Итог, мы собираем на SDK 34 со всем барахлом из зависимостей, которые у нас есть на данный момент и ставим целевую версию в 35. В этом случае мы дошли до «Золотой середины» и Google доволен и времени на очередной апдейт было затрачено минимум.
Надеюсь будет полезно всем тем, кто вынужден использовать костыли.
Комментарии (4)
Cyber_Griffin
12.08.2025 07:40Мой опыт:
— 3 древних проекта, куча модулей, deprecated-код, а заказчик говорит: «Это же просто цифры поменять, да?»
— Android SDK Update Assistant? Смешно. Пришлось вручную ковыряться в граблах, как археолог в руинах.
Cyber_Griffin
12.08.2025 07:40Какой из этого вывод
Google хочет, чтобы все приложения были современными, но забывает, что половина кода в индустрии — легаси на грани археологии. Бизнес не хочет тратить время на апдейты, пока Google не пригрозит баном. Разработчики сидят сif (SDK_INT > UPSIDE_DOWN_CAKE)
и мечтают о переписывании всего с нуля.
lsillarionov
12.08.2025 07:40а,
List.getFirst()
, уже классическая подстава от Kotlin. Хорошо, что она описана в официальных гайдах по обновлению, есть в youtrack jetbrains.
Rusrst
Зачем вы пишите мобильные приложения с таким подходом? Они же у вас и выглядят 100% как кусок фекалий (поправим какие-то отступы, а ничего, что там инсеты надо обрабатывать уже, predictive back использовать). Вы за год не способны понять и донести что нужно время на обновление? 35 api вышло не вчера как бы.
Я даже боюсь представить какой вы там c/cpp код с такими подходами пишете...