IssueTracker

First of all thanks for this detailed issue.

This issue had been investigated thoroughly when it was first reported internally. The surprising detail in this report is that the issue is not reproducible before 1.7. I will look into this.

The main problem with POBox is the fact that it is deprecated. Since 2021 Sony has been shipping new Xperia devices with Gboard pre-installed. Although we are aware that there is still a considerable amount of users still using POBox, the described behavior is caused by POBox's noncompliant behavior with InputConnection and InputMethodManager documentation. However, this is understandable since TextView implementation was also not respecting the behavior that is expected from Editors.

Ultimately we have decided to enforce the documented behavior with specifically regards to when editors should call InputMethodManager.updateSelection. Also, although unconfirmed, there were traces of possible custom code being included in Sony OEM images that changed how InputMethodManager was notified from TextView. If POBox also depended on something like this, it would be impossible for Compose code to replicate the same unknown behavior.

Just to be sure, it is dangerous to replace Compose TextField with Android View EditText as a workaround for this issue.

Compose 1.7 has a bug that causes ANR when the focus is on EditText. https://issuetracker.google.com/issues/369354336

Another View-related bug in Compose 1.7 is that an Android View is focused by calling FocusManager.clearFocus(). https://issuetracker.google.com/issues/374031296

Perhaps there is a lack of testing of Compose 1.7 in combination with Android View. There is also a possibility that there are other fatal bugs related to View.

In other words, the only options for apps targeting the Japanese market that require POBox support are to continue using Compose 1.6 or to use EditText in combination with various workarounds.

Project: platform/frameworks/support
Branch: androidx-main
Author: Halil Ozercan <halilibo@google.com>
Link:      https://android-review.googlesource.com/3317256

Fix POBox keyboard issue

Fix POBox keyboard issue 
 
Fix: 373743376 
Fix: 329209241 
Test: NullableInputConnectionWrapperTest 
Change-Id: I94e0e598274fb88b255f977f9fbd50dfbbb1ecb1

Many thanks again for this report. Especially for giving us a huge clue in terms of what could be going wrong. The fix is now merged and I will ask for a cherry-pick into a stable release.

Yes, this fix is planned to be included in a future 1.7.x release.

Thanks for the fix. Sorry to follow up on this. is it possible for you to share specific release version/date for the stable version? We are waiting on this to decide on our direction.

result of recent decision to have it depend on runtime

I wonder if it's still fair to call it animation-core at this point. How about we move everything in animation-core to animation, and the ui bits go to ui-animation? So we would have:

// Compose animation library (transition / single value animation etc)
androidx.compose.animation:animation

// Animation integration for Compose UI (crossfade / animated modifier, etc)
androidx.compose.ui:ui-animation

Yes, assuming we do decide to move animation into ui group, then it makes total sense to rename animation-core to animation. :)

Is this actually obsolete? We still have a dependency on :compose:animation:animation-core from compose:ui:ui

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/ui/ui/build.gradle;l=45

Looks like this is used in our animated vector support, shouldn't these be moved up to a separate module? (having an api dependency here in particular seems very worrying..)

Seems like it's a different reason for the dependency now - previously it was ambient animation clock. Splitting animation and animation-core in separate groups is no longer a viable option. Moving animation group up is reasonable as long as we could sort out the dependency issue. :)

Looping in Yuichi, owner of animated vector. Yuichi, would it be possible to move the animated vector impl to the animation group or another module that depends on both animation and ui? If I remember correctly, we tried that approach and ended up with a bunch of extra APIs to support cross module communication. :(

Louis, how critical is this? This would require a large refactor that I think might be too late at this stage of Beta. :(

My understanding is that we don't currently have a circular dependency, just a module separation that isn't critical to have anymore, right?

My understanding is that we don't currently have a circular dependency, just a module separation that isn't critical to have anymore, right?

We still have a cycle between library groups:

animation:animation depends on ui:ui which depends on animation:animation-core

This will make it very difficult to independently version these library groups (ui and animation), since if a developer increases the version of ui:ui, it might actually end up increasing the version of animation:animation-core too.

if that's the case then either animation and ui are effectively part of the same version group, or animation and animation-core are separate version groups of their own and may not establish and use opt-in internal APIs between them.

animation and ui are effectively part of the same version group

What would this look like? I'd rather not put a hard requirement to never use internal or experimental APIs across the two animation libs, which would be required by the other option.

After some investigation, I think we can eliminate the dependency from ui to animation to simplify things a bit. This would require refactoring out the impl of animated-vector that depends on animation group into a separate module. Since the animated-vector features are experimental, this can be done post 1.0.

However, there is unfortunately another group level dependency cycle:

foundation (from foundation group) -> animation -> foundation-layout (from foundation group)

I don't see a good way to avoid this without creating hurdles that'd make animation feature development difficult. It is somewhat analogous to the group level dependency story between fragment and lifecycle:

 lifecycle-extensions (from lifecycle group) -> fragment -> lifecycle-viewModel/livedata-core (from lifecycle group)

Louis is right that independent versioning would be difficult. Animation and foundation would need to be released in lock steps, similar to lifecycle and fragment. It's still lesser of the two evils, compared to splitting animation libs. The animation lib requires animation-core to add new low-level experimental APIs (for example: Transition.createChildTransition) to support high level animation features. Not allowing experimental API usage between these two libs would therefore hinder feature development.

foundation (from foundation group) -> animation -> foundation-layout (from foundation group)

We have usages in Crossfade and AnimatedVisibility

Crossfade just uses a Box as an implementation detail, we can probably refactor that out and just build our own simpler box for internal usage.

AnimatedVisibility has (experimental) extensions for RowScope and ColumnScope, which seems more problematic.

Do these extensions need to live here? Or when the underlying APIs are stable, could they live in foundation-layout? It seems reasonable that ColumnScope / RowScope animation implementations, live in the same place that they are defined, then we could remove this dependency inversion. I would really like to avoid the case where updating your animation dependency so you can make use of new animation APIs also ends up updating how Row behaves.

I would really like to avoid the case where updating your animation dependency so you can make use of new animation APIs also ends up updating how Row behaves.

I understand the desire to make the two libs independent. I'm in full support of removing the dependency on animation from ui group.

Updating how Row behaves when updpating animation may be desired because going forward we'll lean more and more on foundation-layout to reuse some of the implementation so that animation doesn't need to reinvent the wheels and implement the same layout logic. For example, I'm planning on implementing AnimatedRow, for which I'd prefer to reuse as much from the Row's static layout/spacing logic as possible, rather than duplicating the code. I won't be able to put something like AnimatedRow outside of animation, because animating values not known until measure/layout is not supported in stable animation API yet.

Do these extensions need to live here? Or when the underlying APIs are stable, could they live in foundation-layout? It seems reasonable that ColumnScope / RowScope animation implementations, live in the same place that they are defined, then we could remove this dependency inversion.

That's a great question. We are just starting with the layout animation APIs. There will be more and more cases where we'd put out experiemental animation APIs, as well as their Row/Column specific variant. The Row/ColumnScope extension of AnimatedVisibility account for the majority API use for AnimatedVisiblity nowadays, because they are tailored to the specific layouts and therefore more convenient. We'd hurt the dev experience more than we gain if we had to take that (and future opportunities of) optimization away.

Doris and I chatted; it looks like a promising path forward is aligning the compose-animation modules with the foundation version group and breaking the dependency from compose-ui on animation-core. The only usages in a quick survey are the experimental animated vector support, tests, and samples. If we move the experimental animated vector support to a foundation-level module that depends on animation, we can keep the compose-ui <-> compose-foundation version boundary strict.

Yes, that was also what I meant in #21 by "removing the dependency on animation from ui group."

Yuichi has kindly agreed to take on the task to move the animated vector work out of ui, therefore removing ui's dependency on animation-core. We can cherry-pick that change into release branch once it lands. (https://android-review.googlesource.com/c/platform/frameworks/support/+/1748158)

I'll fix the tests' and sample's dependency on animation from ui in a follow-up CL.

Follow-up is at: https://android-review.googlesource.com/c/platform/frameworks/support/+/1750079

It'd be nice to enforce the lib group dependency so it can only be one-way from higher level groups on lower level groups. Filed feature request at b/192389944 to track that.

In 1.0.0 the animatedvectorresource and the AnimatedImageVector is missing. please release it as soon as possible as it is causing issues with my app. please sugest some workaround as my app heavely depend on it.

Re #28:

AnimatedVectorResource will be included in the next Compose release in 1-2 weeks in a new lib: animation-graphics. Stay tuned! Sorry for the inconvenience.

Thanks