Let's say I need to migrate targetSdk to 33, and m...
# android
t
Let's say I need to migrate targetSdk to 33, and my app contains many modules in different repos which has its own targetSdk. Is it required to update targetSdk in all modules?
not kotlin but kotlin colored 4
j
AFAIK technically you can upgrade only the app module and it should be fine since everything should be backwards compatible. But when stuff is complex this might get out of hands, since there are still changes to behavior for targetSdk which might affect other modules
I would highly recommend to have the same target and min sdk for all modules 😄
👍 1
e
Late to the party: • Technically you can have different targetSdks • Ideally you should aim to have the same one.
👍 1
t
Do you have any idea on how to unify all minSdks and targetSdks in one place? Currently they are in different repos for each module.
h
a main toml, in which the versions are defined
d
toml + plug in convention - one applied to the app module and another applied to all modules or I think you can apply the settings at a global level and pull the value in from a toml (haven’t tried that yet in order to consolidate replications between build conventions). Found it. Also, do know that Gradle has their own slack forum that is helpful to find details like this: https://gradle-community.slack.com/archives/CJYS1DAP5/p1682796729312809?thread_ts=1682785118.420389&cid=CJYS1DAP5
e
TL;DR: It's better to keep the library targetSdk versions higher or equal than the app's version Think of
targetSdk
as "the latest version of Android on which I've tested my app and it works". So as long as you test your app and it works you're fine, meaning that changing your app's
targetSdk
version is enough and it's not required to update the library modules. BUT, you're unlikely to test every single possible scenario, so it's better if your dependencies (lib modules and third-party libs) have a higher or equal
targetSdk
version than the app module. Then lint and other tools can catch some of these issues at compile time or in tests. The app module's version will take precedence, it's ultimately what the app will be packaged with and what the OS will see. However, the Android Gradle Plugin will take the libs' versions into account and make some changes to the merged manifest file, e.g. add permissions. My recommendation would be to share the same
targetSdk
version across all library modules, e.g. by using convention plugins, but set the app's version explicitly in its build file