feat: edge-to-edge mode on Android

[kirillzyusko]

Explanation of Change

• Enabled edge-to-edge mode (removed a patch from keyboard-controller)
• implemented custom KeyboardAvoidingView for Android - ideally we should use the implementation from react-native-keyboard-controller, but in this case animations have a very poor performance and it's better to investigate/fix as a separate issue
• applied a patch for Modal (that adds navigationBarTranslucent property - applied for react-native and react-native-modal)

Linked HybridApp PR: https://github.com/Expensify/Mobile-Expensify/pull/13299

Fixed Issues

$ #51673
$ #52116
PROPOSAL: #52116 (comment)

Tests

• Go through the all screens in the app and be sure keyboard avoiding works as before (test on Android < 12 with 3 buttons navigation bar type and on Android 12+ with gesture navigation bar type);
• Make sure that on Samsung devices when device has light theme and you turn on dark theme in app the navigtion bar has a dark color (i. e. matches the app preferences)

Offline tests

N/A

QA Steps

• Go through the all screens in the app and be sure keyboard avoiding works as before (test on Android < 12 with 3 buttons navigation bar type and on Android 12+ with gesture navigation bar type);
• Make sure that on Samsung devices when device has light theme and you turn on dark theme in app the navigtion bar has a dark color (i. e. matches the app preferences)
• [HybridApp ONLY] Test app switching between NewDot and OldDot to ensure no styling bugs occur after this transition

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

[kirillzyusko]

@shawnborton would it be possible to ask you to test this PR? This PR should unify how Android app is handling insets (now it'll be identical to iOS). This PR is a logical continuation of this #51956 but the key difference is that now we don't manage color of navigation bar independtly - now we make all system bars (navigation bar, status bar) transparent by default, so it matches iOS app style.

The reason why I want you to test and give your feedback, is because some elements look good on iOS, but looks not very good on Android. For example, navigation bar padding on Android vs iOS:

Coefficient	Android	iOS
0.7 (default for iOS)
1

This is the one issue I spotted at the moment, but maybe you find more - your feedback is very valuable 🙏

@mountiny would it be possible to trigger a build so that @shawnborton can test the app?

[shawnborton]

I can trigger a test build. I don't have an Android with me at the moment but I believe @dubielzyk-expensify can help us test!

[kirillzyusko]

but I believe @dubielzyk-expensify can help us test!

Sounds good! Any look from UX/UI team will help a lot ❤️

[shawnborton]

We might need to take the PR out of draft in order to run the test build. If we don't get a test build posted in the next 20 minutes or so, let's try that.

[shawnborton]

Well wouldya just look at that, ready for testing.

[mountiny]

Assigned @c3024 for c+ review

[dubielzyk-expensify]

Tested this on Android now. Definitely agree with this comment that we should add some tiny padding above the home indicator. Scenarios where we use cards get a bit weird so hopefully that'll fix this too:

I'm not sure exactly where the padding is applied, but the footer buttons seem to get excessive padding on some screens:

Other than that, this is looking good.

I think in an ideal world, I'd prefer both home indicators on iOS and Android to be transparent instead of using appBg color, but that's probably a separate PR and issue altogether.

[shawnborton]

Nice testing Jon, thanks for running through the screens and I agree with your feedback.

[kirillzyusko]

Awesome @dubielzyk-expensify ! 🔥 Thank you for your feedback!

[mountiny]

Do we need a new build @kirillzyusko

[kirillzyusko]

@mountiny no, not yet. Tomorrow I want to test on more devices and if everything works well, then I will ask for additional testing 😊

[kirillzyusko]

I had to add this library again, because we need to manage navigation bar button style (dark/light).

Since user can customize the theme of app independently to device settings we also have to manage it dynamically from JS code.

I checked and one method that we use (setButtonStyleAsync) doesn't use deprecated API. However I remember, that this particular library wasn't accepted in the first round of fixing the nav bar color management, so i'm happy to discuss further steps here 🙌

[mountiny]

@kirillzyusko I noticed you are adding the library here again even though in Slack we agreed not to use it https://expensify.slack.com/archives/C01GTK53T8Q/p1731618817760309?thread_ts=1731092817.909359&cid=C01GTK53T8Q

Can you please come back to the thread and summarize the problems you are facing with not using the library or explain clearly why we cannot just handle this on our own? Thanks!

[Julesssss]

Thanks Vit, I missed this but agree with needing to discuss this further.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, Desktop, and Web. Happy testing! 🧪🧪

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.amazonaws.com/android/52392/index.html	https://ad-hoc-expensify-cash.s3.amazonaws.com/ios/52392/index.html
Desktop 💻	Web 🕸️
https://ad-hoc-expensify-cash.s3.amazonaws.com/desktop/52392/NewExpensify.dmg	https://52392.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[mountiny]

@c3024 let us know when you complete the testing please! thanks!

[c3024]

Android: Native

WhatsApp.Video.2024-11-25.at.20.52.49.mp4

WhatsApp.Video.2024-11-25.at.21.28.15.mp4

Android: mWeb Chrome

WhatsApp.Video.2024-11-25.at.20.57.38.mp4

iOS: Native

RPReplay_Final1732548627.MP4

iOS: mWeb Safari

RPReplay_Final1732548716.MP4

MacOS: Chrome / Safari

endChrome.mov

MacOS: Desktop

Screen.Recording.2024-11-25.at.9.23.19.PM.mov

Tests well!

[mountiny]

Thanks!

[mountiny]

Mobile-Expensify pr merged

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[github-actions]

🚀 Deployed to staging by https://github.com/mountiny in version: 9.0.67-0 🚀

platform	result
🤖 android 🤖	false ❌
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅
🤖🔄 android HybridApp 🤖🔄	success ✅
🍎🔄 iOS HybridApp 🍎🔄	success ✅

[github-actions]

🚀 Deployed to production by https://github.com/mountiny in version: 9.0.67-9 🚀

platform	result
🤖 android 🤖	skipped 🚫
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅
🤖🔄 android HybridApp 🤖🔄	failure ❌
🍎🔄 iOS HybridApp 🍎🔄	failure ❌

[jayeshmangwani]

Coming from this issue #53180 , we were using the height and width values from the useWindowDimensions hook, which caused extra height above the suggestion modal. To address this, we have switched to using useWindowDimensions from 'react-native' instead context on this is here #53180 (comment).

[shubham1206agra]

Due to newer implementation of native-stack, the KeyboardController is not working properly. This caused #53351