Android 15: Handle edge to edge insets

[nbradbury]

Fixes #21605

This PR is a follow-up to #21599 that updates targetSdkVersion from 14 to 15, which defaults to using edge-to-edge.

To support this, I added BaseAppCompatActivity which is now used throughout the app where we previously extended AppCompatActivity. This enables us to enforce edge-to-edge insets. I can't say I'm wild about my solution, but it has the benefit of keeping the inset logic in a single class instead of scattering it throughout the app.

The goal here was not to overhaul our UI with full edge-to-edge support, but instead to update both compileSdkVersion and targetSdkVersion to 35 without any noticeable changes.

To test, run the app on SDK 35+ with gesture navigation both enabled and disabled and ensure the screens appear correctly, especially in regards to the status bars and navigation bars. Then run the app on an older device and ensure the same.

Note: Don't be daunted by the number of files changed - the vast majority of them involved nothing more than updating activities to extend BaseAppCompatActivity instead of AppCompatActivity.

[dcalhoun]

The changes look good to me. Please feel free to await additional review, if desired.

I can't say I'm wild about my solution, but it has the benefit of keeping the inset logic in a single class instead of scattering it throughout the app.

Will you expand on what you dislike about the solution?

I perceive this to be a temporary solution to help us iterate towards better support of the latest SDK features. With that in mind, and given how widespread we need to apply these changes, the abstraction you present makes sense to me.

I tested the changes in various ways—SDK 35 and SDK 30, portrait and landscape, gestures enabled and disabled, etc. I only noted one small regression on the login screen, where a small gap without a background color is displayed beneath the login screen.

Before	After

[nbradbury]

Will you expand on what you dislike about the solution?

Well, I think it's not necessarily a bad solution, and it is a clean way to handle so many activities in one place. I guess it's just not a very Android-y solution. I would've preferred to do everything in styles.xml, but as you stated correctly, this is a temporary solution, and updating the styles for so many activities would've been a lot more involved (and most likely would need to be redone down the road).

[nbradbury]

I only noted one small regression on the login screen, where a small gap without a background color is displayed beneath the login screen.

@dcalhoun I really need to borrow your eyes, because I never would've seen that had you not pointed it out. I'll take a look at what's causing this, but if nothing obvious turns up I'm good with merging as-is.

[ParaskP7]

👋 @nbradbury and thanks for this PR!

I am not the best when it comes to UI, nor I applied extensive testing to verify everything is working as expected when it comes to edge-to-edge. But, throughout the screens I did navigate, for both, Jetpack and WordPress apps, UI seems okay to me.

PS: I undertand that @dcalhoun did a more thorough pass at all screens, he even found this login diff (kudos), this might be enough.

---

Having said that, I want to debate a bit about base classes and this new BaseAppCompatActivity, with the trend moving towards more flexible, modular approaches that prioritize composition and single-responsibility principles.

I would've preferred to do everything in styles.xml, but as you stated correctly, this is a temporary solution, and updating the styles for so many activities would've been a lot more involved (and most likely would need to be redone down the road).

Unfortunately temporary solutions tend to stick unless they are being planned to be reworked. Is there something we are planning to do on that in the future, an issue or project of some kind? 🤔

private val excludedActivities: HashMap<String, ActivityOffsets> = hashMapOf(...)

Finally, this here is what makes me more uncomfortable. I've seen from the commits history that you tried different approaches. I just wonder whether this approach is too scalable, whether it will introduce implicit "bugs", or what might the maintenance overhead be for us going forward. 🤔

PS: This all above is just my 2-cents, I don't want to block this PR or development going forward, just wanted to elevate awareness. 🙏

[nbradbury]

Unfortunately temporary solutions tend to stick unless they are being planned to be reworked.

💯

Is there something we are planning to do on that in the future, an issue or project of some kind?

Point taken. No, there are no solid plans, just my own informal plans on revisiting this.

Finally, this here is what makes me more uncomfortable. I've seen from the commits history that you tried different approaches. I just wonder whether this approach is too scalable, whether it will introduce implicit "bugs", or what might the maintenance overhead be for us going forward.

I think the biggest potential issue with this approach is future devs knowing they need to add new activities to this BaseAppCompatActivity class.

But overall, I do agree with you. There's a certain "code smell" to my approach, and I welcome alternative solutions. My big concern was wanting to avoid scattering code throughout the app to handle edge-to-edge. I do like the idea of relying on styles.xml but even that isn't as consolidated as I would like.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[nbradbury]

I'm going to merge this as-is due to the number of affected files. Everything works as expected, but we agree a different approach might be better.

[sentry-io]

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

• ‼️ ApplicationNotResponding: ANR org.wordpress.android.ui.LocaleAwareActivity in... View Issue

_{Did you find this useful? React with a 👍 or 👎}