revert PR #1902 simplify edge-to-edge preference logic in CordovaActivity and SystemBarPlugin#1962
Conversation
…vity and SystemBarPlugin - Android EdgeToEdge was introduced in Android 15 and should only be used from there on - Add small comment to the condition
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1962 +/- ##
=======================================
Coverage 61.43% 61.43%
=======================================
Files 24 24
Lines 4922 4922
=======================================
Hits 3024 3024
Misses 1898 1898 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
This PR makes no sense for me. The definition of edgetoedge is to have the app extend to the full edge of the device. The configuration does not say edgetoedge from android 15. It should apply to all versions of android. It up to the developer of the application to manage the inserts of the app in this case. What the option |
|
Adding to my previous comment, in PR that is being reverted here (#1902), I see that this was motivated by the comment from erisu. That PR did not just try to re-implement EdgeToEdge defaults to In my case, with the previous PR and EdgeToEdge enabled the insets are managed in the style of the application in both top and bottom. The style is the same through all version of android. |
|
Correctly, this PR is motivated by erisu's comment on PR #1902. I looked through the edge-to-edge guide of Android and thought there is a preference flag or something introduced by Android 15, which is reflected by the Cordova preference |
|
Yah I don't agree with reverting PR 1902.
I think this is just a safe area inset issue... when in operating in edge to edge, the developer is going to have to be mindful of screen obstructions and accommodate appropriately.
Android is going to enforce E2E mode on modern API levels and moving forward. Cordova however makes opting into E2E completely optional by recreating the old "system" bars such as the status bar and positioning the webview as it would have on older API levels -- so while the app is technically operating in E2E fashion the webview itself sits within the safe content area and users don't have to worry about refactoring their app to handle safe area insets. For users that DO opt into E2E mode, I would expect that would apply to all API levels reasonably possible. That is unless if there is a strong reason not support E2E on older devices, we should support it so that app developers can get a consistent behaviour look and feel across API levels. Natively, that is exactly what E2E mode in the behavioural sense is not new ... ever since Android 5 (or 6, whenever Android gave us more control over the status bar) I've been using an "E2E" look 'n' feel by having the status bar an overlay on top of the webview, and using insets to pad content appropriately. So I don't see any reason why we couldn't support E2E mode for pre android 15. |
Thanks that you explained everything in detail. I think also, to make development for the users not harder as it should be, this should be allowed on older APIs also. Maybe I can use some things you mentioned here for documentation. |
Do you mean, when Android enforces edge-to-edge it is ok to use just cordova-android 15 and let the preference |
|
I updated the documentation for |
Platforms affected
Motivation and Context
window.statusbar.visible = false;Description
Testing
Checklist
(platform)if this change only applies to one platform (e.g.(android))