NEVISACCESSAPP-5853: Updated Android configuration to use Gradle 8.4.0 and above and AGP 8.3.0 and above #53
Conversation
…0 and above and AGP 8.3.0 and above NEVISACCESSAPP-5853: Updated Android configuration to use Gradle 8.x
laszlo-domonkos
requested review from
daniel-toth-leeder,
tamas-toth and
balazs-gerlei
| targetSdkVersion flutter.targetSdkVersion | ||
| targetSdkVersion 34 |
There was a problem hiding this comment.
❓ I don't know this about Flutter, but what is the reason to no longer use flutter.targetSdkVersion? It's just strange to me that so far we relied on that and now we explicitly define it. I understand that we want to update but can't we update flutter.targetSdkVersion somehow and if not, wouldn't it cause a problem if we use a different targetSdkVersion?
There was a problem hiding this comment.
This variable is defined in the Flutter SDK and cannot "update" it. As far as I can remember it is still to low or at least other than 34. I don't have any objection with overriding it.
There was a problem hiding this comment.
Yes, @tamas-toth is right. There is no way to set its value, so we cannot use that variable because its value is still 33, but it really depends on the installed Flutter SDK. As Google Play Store restricted to use 34 I would not use this variable but using a strict value instead.
There was a problem hiding this comment.
Isn't this defined here? If so, it seems to be 34 already, what is the reason that it's not the same for us?
There was a problem hiding this comment.
We discussed this in a Huddle and my worry is basically that the targetSdk defines what restrictions apply to a certain app when running on Android. Having a higher targetSdk for an app than what is defined in a library (in this case Flutter itself) is not necessarily a problem but it can be. The library maintainers could only assume restrictions that the targetSdk they defined bring with it when writing their library so it is possible that the newer restrictions that the app applies to it with a higher targetSdk cause a bug or even a crash.
For example Google started to restrict the usage of private APIs in the recent Android versions and these restrictions only apply to apps if they define these newer Android versions as their targetSdk. So it is possible that for example Flutter developers assumed it is okay to call into one of such private APIs via reflection and it is only true for the targetSdk they defined.
For these reasons I think it would be better to set the targetSdk version (and also compileSdk) to the same as the Flutter version that the app uses, but that would mean we need to upgrade to newer Flutter version (I checked and the next one, 3.22.0 already defines 34 as the targetSdk version) which is a bigger task.
We should consider and discuss this, but for the time being, I think it's okay to override targetSdk here and I won't forgo approving the PR for this reason. Even if we agree to upgrade Flutter, it can be done as a follow-up.
Fixed. |
No description provided.