fix(Android, Stack): Moving formsheet above keyboard

[t0maboro]

Description

This PR improves the way the BottomSheet on Android handles the on-screen keyboard (IME). Previously, the keyboard was not respected properly - opening the keyboard could cause content to be partially or fully obscured due to incorrect handling of insets.

With this update:

1. We listen to dynamic bottom IME insets to track the keyboard position in real-time.
2. The BottomSheet's Y translation now directly reflects the current IME inset, preventing it from being overlapped by the keyboard.
3. Since we have implemented custom enter/exit animations (fade + slide), IME insets must be taken into account both during animations and in live state updates to avoid layout jumps.

There are two key touchpoints where we react to IME inset changes:

• During enter/exit animations: When autofocus is enabled or when entering/leaving with the keyboard open, we need to align the BottomSheet's position with the keyboard height continuously.
• In the onProgress callback: This listens to dynamic IME inset changes outside of enter/exit animations — e.g. when the keyboard resizes or changes without the BottomSheet visibility changing.

Priority is given to the animation layer for transforming the component's position, while the onProgress callback serves as a fallback when animations are not active. This prioritization enables us to maintain a smooth and consistent visual appearance across all lifecycle scenarios of the BottomSheet.

Fixes: #3181

Changes

• Aligned the method for calculating available space for bottom sheet with Android
• Fixed the height calculation on KeyboardDidHide state for fitToContents
• Synchronized translationY updates between our custom entering/exiting animations with onProgress callback from insets listener.
• Added a new example for testing this scenario

Screenshots / GIFs

Here you can add screenshots / GIFs documenting your change.

You can add before / after section if you're changing some behavior.

Before

test3248-main.mov

After

test3248.mov

Test code and steps to reproduce

Tested on android with Test3248

Tested with API levels 29 or higher, because I noticed another issue regarding bottom sheets on 28: https://github.com/software-mansion/react-native-screens-labs/issues/480

Checklist

• Included code example that can be used to test this change
• Ensured that CI passes

[t0maboro]

Moving back to draft for a while, because I noticed some issues with autofocus and textinput below API 30

[kligarski]

I had already started the review before you moved the PR to draft so I'll finish it.

This looks great! I have some remarks/questions:

1. Just to be sure, this is not a regression, right? (not respecting navigation bar insets)

Screen_recording_20250929_140451.mp4

2. Do you think we can do something about the gap between keyboard and formsheet when they're both hiding at the same time? Should we create a ticket to investigate it in the future?

Screen_recording_20250929_135928.mp4

3. We should probably revisit #2925 to fix this, right?

Screen_recording_20250929_140440.mp4

[t0maboro]

@kligarski answering your questions:

1. Imo not a regression, because as a top edge I was considering top edge of the component, the same way as we'd put detent=1.0 previously. However, we should definitely consider whether this is still valid, as now we're avoiding the keyboard. cc @kkafar if you have any thoughts on that

2. I created a ticket on labs repo https://github.com/software-mansion/react-native-screens-labs/issues/484, but the problem here is that I'm dependent on onProgress callback, which will cause a slight delay.

3. For status bar, I'd prefer to continue the work in fix(Android): status bar insets for formSheet #2925 - I can take it over and adapt to this PR (until anyone has any objections of at.1 whether the status bar is a regression or not)

[kligarski]

@kligarski answering your questions:

Imo not a regression, because as a top edge I was considering top edge of the component, the same way as we'd put detent=1.0 previously. However, we should definitely consider whether this is still valid, as now we're avoiding the keyboard. cc @kkafar if you have any thoughts on that

I'm not sure if we're talking about the same thing: I meant the text input being placed behind navigation bar (3-button navigation at the bottom) in first fitToContents example. I checked the main and confirmed that this is not a regression so we're good.

[t0maboro]

@kligarski answering your questions:
Imo not a regression, because as a top edge I was considering top edge of the component, the same way as we'd put detent=1.0 previously. However, we should definitely consider whether this is still valid, as now we're avoiding the keyboard. cc @kkafar if you have any thoughts on that

I'm not sure if we're talking about the same thing: I meant the text input being placed behind navigation bar (3-button navigation at the bottom) in first fitToContents example. I checked the main and confirmed that this is not a regression so we're good.

Sorry, I read all together before answering and idk why I started thinking that 1 and 3 are connected. Good that we have an alignment on this one, but we should rethink whether this is expected now