android 15: adapt layout to edge-to-edge enforcement

[SomberNight]

We need to bump the android targetSdkVersion to 35 (android 15).
As part of that, we need to adapt to the "Edge-to-edge enforcement"

pic

patch

diff --git a/contrib/android/buildozer_qml.spec b/contrib/android/buildozer_qml.spec
index a0e4e6709c..e19bcac5ab 100644
--- a/contrib/android/buildozer_qml.spec
+++ b/contrib/android/buildozer_qml.spec
@@ -108,7 +108,7 @@ android.permissions = INTERNET, CAMERA, WRITE_EXTERNAL_STORAGE, POST_NOTIFICATIO
 android.api = 31
 
 # (int) Android targetSdkVersion
-android.target_sdk_version = 34
+android.target_sdk_version = 35
 
 # (int) Minimum API required. You will need to set the android.ndk_api to be as low as this value.
 android.minapi = 23

---

This is a sub-issue of #9899

[SomberNight]

Could you take a look at this when you have time, @f321x ?

[SomberNight]

related kivy/python-for-android#2969

[f321x]

So there seem two possible approaches to this:

1. Bumping to Qt 6.9 and using SafeArea in QML https://doc.qt.io/qt-6//qml-qtquick-safearea.html#details.
2. Getting python-for-android/pythonforandroid/recipes/android/src/android/display_cutout.py in our python-for-android fork and using get_height_of_bar() to get the size of the status/navigation bars and add an according margin in qml.

1.) seems cleaner however I am unsure if there may be any major obstacles to expect when bumping Qt? Maybe you know if this is realistic in the short therm/what issues could arise from this @accumulator?
2.) Seems more approachable in regards to the play store deadline, so i will try to do this soon unless there are favorable arguments to do the qt bump instead. Once we have Qt 6.9 at one point it should be trivial to replace with SafeArea if needed.

[accumulator]

Bumping to Qt6.9 is not trivial due to the following

1. Material styling has changed significantly, this has impact in many places on the QML side. QML also has some weird quirks, it would not surprise me that there are subtle behavior changes between Qt6.4 and Qt6.9.
2. In QML, assignment of custom property types has issues since Qt>=6.6. This would mean a least changing all types in the QML<->QObject boundary to a generic type. (see also: https://www.riverbankcomputing.com/pipermail/pyqt/2024-June/045922.html)
3. Newer Qt means newer NDK. Might need patches in dependencies, might have reproducibility issues.
4. Possible new reproducibility issues building Qt

1 & 2 are not complex, but it will result in huge diffs, so this will have friction with pending pull requests.

[accumulator]

IMO we need the option to release without the bump to Qt6.9, just in case.

[SomberNight]

(Re bumping the qt version, it would already be a worthwhile step to try to bump to 6.5, as IIRC some QML styling already changed between 6.4 and 6.5 and we could do the necessary styling changes on our side. Incremental progress is good enough, we don't need to jump ahead years at a time.)

[accumulator]

(Re bumping the qt version, it would already be a worthwhile step to try to bump to 6.5, as IIRC some QML styling already changed between 6.4 and 6.5 and we could do the necessary styling changes on our side. Incremental progress is good enough, we don't need to jump ahead years at a time.)

At least it would look the same on desktop as on device (since pyqt6-qt6==6.4.x on pypi doesn't work) :D