IssueTracker

Seems to be a DNS problem with systems that have 'obtain DNS server address automatically'. Changed my system to a manual setting and the browser etc now work. SDK 2.2 didn't seem to mind the auto setting though.

Could you please describe how/where you changed your system to a manual setting?

Based on its date, this issue was originally reported before Android 2.3. Because of the many changes that existed in Android 4.x compared to previous versions, it's very likely that this issue doesn't exist in recent versions of Android like 4.2.2 or newer. Because of the high likelihood that this issue is obsolete, it is getting closed automatically by a script, without a human looking at it in detail. If the issue still exists on a Nexus 4 or Nexus 7 running Android 4.2.2 and is not related to Google applications, please open a new report accordingly.

java.lang.IllegalArgumentException: Unable to locate adb
        at com.android.tools.idea.run.editor.DeployTargetPickerDialog.<init>(DeployTargetPickerDialog.java:144)
        at com.android.tools.idea.run.editor.ShowChooserTargetProvider.showPrompt(ShowChooserTargetProvider.java:113)
        at com.android.tools.idea.run.AndroidRunConfigurationBase.getDeployTarget(AndroidRunConfigurationBase.java:600)
        at com.android.tools.idea.run.AndroidRunConfigurationBase.doGetState(AndroidRunConfigurationBase.java:281)
        at com.android.tools.idea.run.AndroidRunConfigurationBase.getState(AndroidRunConfigurationBase.java:241)
        at com.intellij.execution.runners.ExecutionEnvironment.getState(ExecutionEnvironment.java:158)
        at com.intellij.execution.runners.BaseProgramRunner.execute(BaseProgramRunner.java:55)
        at com.intellij.execution.runners.BaseProgramRunner.execute(BaseProgramRunner.java:50)
        at com.intellij.execution.ProgramRunnerUtil.executeConfigurationAsync(ProgramRunnerUtil.java:92)
        at com.intellij.execution.ProgramRunnerUtil.executeConfiguration(ProgramRunnerUtil.java:41)
        at com.intellij.execution.impl.ExecutionManagerImpl.restart(ExecutionManagerImpl.java:93)
        at com.intellij.execution.impl.ExecutionManagerImpl.access$300(ExecutionManagerImpl.java:44)
        at com.intellij.execution.impl.ExecutionManagerImpl$3.run(ExecutionManagerImpl.java:442)
        at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:232)
        at com.intellij.util.Alarm$Request.runSafely(Alarm.java:356)
        at com.intellij.util.Alarm$Request.run(Alarm.java:343)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at com.intellij.util.concurrency.SchedulingWrapper$MyScheduledFutureTask.run(SchedulingWrapper.java:228)
        at com.intellij.openapi.application.TransactionGuardImpl$2.run(TransactionGuardImpl.java:315)
        at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.doRun(LaterInvocator.java:435)
        at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.runNextEvent(LaterInvocator.java:419)
        at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.run(LaterInvocator.java:403)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:762)
        at java.awt.EventQueue.access$500(EventQueue.java:98)
        at java.awt.EventQueue$3.run(EventQueue.java:715)
        at java.awt.EventQueue$3.run(EventQueue.java:709)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:732)
        at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:755)
        at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:704)
        at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:391)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

voilà ce qu'on m'affiche lorsque j’exécute mon programme

je ne vois pas comment résoudre ce problème. svp aidez moi

My workaround in the end was to alternate using two different fragment containers and use bringToFront() on the one I that needed to have the highest z-order. It adds extra views to my layout but seems to be the only reliable way to properly have overlaid fragment animations pre-lollipop. Hopefully this will be fixed at some point as it really hampers the view transition possibilities of android compared to something like ios.

[Comment deleted]

I take back my taking back; still an issue in v24.2.0.

Please share the source code and test apk to test this issue.

Note: Please upload the files to google drive and share the folder to android-bugreport@google.com, then share the link here.

Sample repository here:

https://drive.google.com/file/d/0B7sMjo0r5sqlTUFIUjFmNWlnQ28/view?usp=sharing

Here's the corresponding repo w/ gif if others find that more convenient to check out:

https://github.com/stkent/FragmentAnimationBugRepro

Any news on this now a test repo has been provided?

We have passed this defect on to the development team and will update this issue with more information as it becomes available.

Thanks for the update!

Any update on this?

Would love a fix for this.. In my case I need to slide a fragment in over the top of the existing one, it seems a reasonable thing to do and something that ought to work..  Any updates?

Any updates on this?

Should we use one of the workarounds posted here?

The framework behavior for animations display removed views on top of other views and explains why the outgoing Fragment's view appears on top.

While we can't fix the general case here within an unbundled library like Fragments, we can fix this in cases where the parent layout is a FrameLayout / extends FrameLayout by delaying the removal of the old View until after the animation completes under the assuption that children of a FrameLayout are suitably independent that animating one in while the other still exists in the layout is not an issue.

This should at least fix the issue for libraries built on top of Fragments such as Navigation.

If it helps, I wrote a custom layout to hack this behavior: https://github.com/airbnb/native-navigation/blob/master/lib/android/src/main/java/com/airbnb/android/react/navigation/ScreenCoordinatorLayout.java

This looks great, but how do you use it?

By looking at the javadoc it seems you use it as the root container for the activity that'll host the fragments

You have to give it a FragmentManager and tell it when you're about to detach a screen so it knows to reverse the drawing ops
https://github.com/airbnb/native-navigation/blob/master/lib/android/src/main/java/com/airbnb/android/react/navigation/ScreenCoordinator.java#L76

Ignore the fact that this library is a React Native library, it works the same for native apps.

I've made a repository to reproduce bug & avoid bug by using custom view.
https://github.com/kingori/FragmentAnimationTest/tree/master

I've made a custom view group based on ScreenCoordinatorLayout
https://github.com/kingori/FragmentAnimationTest/blob/master/app/src/main/java/com/example/wilson/fragmentanimationtest/FragmentHostLayout.kt

In bug case, Fragment.animateRemoveFragment() is called, but container.post() is not invoked. At this point, container view's endViewTransition() is not called. So I checked if endViewTransition is not called & fragment view's animation is already null, then draw view of current fragment last.

Just a note for anyone trying to use the translationZ work around with alpha animation on the entering view. Unfortunately a positive translationZ will introduce an unwanted shadow beneath the entering view, which produces an brief dimming effect as the view's alpha is animated. This is quite visually jarring. After much experimentation, I realised you can put a negative translationZ on the exiting view to force it behind the entering view without generating any unwanted shadows.

Still, this is was a frustrating and time consuming bug to work around, and I look forward to seeing a fix for this in the Jetpack Navigation library.

I have the same issue, translationZ doesn't seem to be doing anything either :/
We probably need to stick to activities if we want to follow material design guidelines.

I also look forward for this being fixed.

Also, since it's been a long time from the last update, could you please provide information about your progress? Is this ever going to be fixed or would new projects be better off using alternative frameworks?

This also affects me, as I try to use the Navigation Component but I cannot have a transition animation in which the new destination goes on top of the current one. Because the Navigation Component uses "replace" and "setCustomAnimations".

With the Navigation Component, and because of this limitation, is impossible to have an "slide on top" kind of transition.

In order to solve this issue for Jetpack Navigation Component, is it possible to add a ScreenCoordinatorLayout equivalent as main ViewGroup of the androidx.navigation.fragment.NavHostFragment ?
Currently, it's a FrameLayout which has this issue.

From NavHostFragment.java :
@Nullable
@Override
public View onCreateView(@NonNull LayoutInflater inflater, @Nullable ViewGroup container,
                         @Nullable Bundle savedInstanceState) {
    FrameLayout frameLayout = new FrameLayout(inflater.getContext());
    // When added via XML, this has no effect (since this FrameLayout is given the ID
    // automatically), but this ensures that the View exists as part of this Fragment's View
    // hierarchy in cases where the NavHostFragment is added programmatically as is required
    // for child fragment transactions    
    frameLayout.setId(getId());
    return frameLayout;
}

This bug is almost 4 years old now.  Any plan to fix it?  All this push into navigation and fragments, and basic transitions are still broken.

This bug is because of the ViewGroup draw DisappearingChildren at the end of draw, and the replaced fragment's view  is the DisappearingChildren, so it is at the top of new fragment view.

Here may be a solution:
https://stackoverflow.com/questions/32869564/goned-view-draws-on-top-during-layouttransition-disappearing-animator

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 2534c731cc31a615e4584d74327521ec8c5a8aa7
Author: jbwoods <jbwoods@google.com>
Date:   Thu Jun 20 12:42:37 2019

    Draw exit animations first in FragmentContainerView
   
    ViewGroups always draw exiting view animations last. For Fragments, this
    means that the exiting Fragment is always on top of all others. There
    can be no interaction with entering fragments, and there is the
    possiblity of a "pop" when the exit animation finishes to reveal the
    Fragment underneath.
   
    FragmentContainerView overrides the dispatchDraw and drawChild method to
    force all disappearing children to be drawn first. It overrides public
    methods from ViewGroup to build the proper list of transitioning views
    and disappearing child views.
   
    Test: Added units tests, tested visually in app, ./gradlew checkApi
    BUG: 37036000
    Change-Id: I054eaf4ae234258bc7abec22c4c8e559a2c6be71

M       fragment/fragment/api/1.2.0-alpha01.txt
M       fragment/fragment/api/current.txt
M       fragment/fragment/api/restricted_1.2.0-alpha01.txt
M       fragment/fragment/api/restricted_current.txt
M       fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentContainerViewTest.kt
M       fragment/fragment/src/androidTest/res/layout/fragment_container_view.xml
M       fragment/fragment/src/main/java/androidx/fragment/app/FragmentContainerView.java

https://android-review.googlesource.com/987385
https://goto.google.com/android-sha1/2534c731cc31a615e4584d74327521ec8c5a8aa7

So it looks like this change in FragmentContainerView fixes the issue when using exit animations via FragmentTransaction.setCustomAnimations which is great. Another issue very similar to this is the Z ordering of ExitTransitions and EnterTransitions when animating with shared elements. Im able to fix this by using custom animations by overriding ` override fun onCreateAnimation(transit: Int, enter: Boolean, nextAnim: Int): Animation? {`. Is there work being done to make exitTransitions render below the next fragments enter transition?

I'm testing this right now with 1.2.0-alpha01 and realizing that problem is more complex than it seemed. It's still not working properly for me because the behavior should depend on whether I'm going forward or backwards through the fragment back stack. Essentially:

1. When going forward, I want exit animation to be bottom, and enter animation on top
2. When going backwards, I want exit animation on top, and enter animation on the bottom.

That way I could replicate iOS animation behavior where new fragment "comes on top" on previous, but when click back, I also want that fragment to disappear "from the top" and reveal previous fragment beneath it. android:zAdjustment sounds like something that should fix this problem, but is it working for Fragments and Navigation library?

Can anybody help me here?

This fix is not in Fragment 1.2.0-alpha01 - it'll be in alpha02.

Are there way to set which (entering/exiting) fragment should be at top?

Is this it? Is this new Fragment Container View the actual fix for it? https://developer.android.com/reference/androidx/fragment/app/FragmentContainerView
"Fragments using exit animations are drawn before all others for FragmentContainerView. This ensures that exiting Fragments do not appear on top of the view."

Is our long national nightmare of improperly drawn transition animations over?

> Are there way to set which (entering/exiting) fragment should be at top?

^ This. I think ideally we should have a way of telling the Fragment its Z ordering during the animation. I know that are ways, but couldn't find any that works with the Navigation Components.

Hi!

I am experiencing the same issue for version 1.2.3 when using the "FragmentContainerView" and setting "EnterTransition" to a slide transition, and using an exisiting fade transition in "ExitTransition"?

So I am not using "FragmentTransaction.setCustomAnimations", but I guess it is supposed to work the same way?

Hi, I see the same issue as above:
- works with setCustomAninations
- still does not work with setExitTransition / setEnterTransition

It looks like FragmentContainerView.startViewTransition is not called properly in the broken case, which causes that FragmentContainerView falls into the standard drawing path.

Update:

The actual problem with setExitTransition / setEnterTransition is caused by fact that any subclass of Visibility transition (e.g. Fade, Slide, etc.), uses ViewOverlay to realize the animation when the exiting View is removed from its parent. And this is actually happening when performing replace() Fragment transaction. The trouble is than the entering view wont use ViewOverlay and will be effectively BELOW the exiting view :(

It is very sad that such basic usecases are still broken :(
I really cant believe that it was not catched earlier :(

As a workaround,  one may try to write customized FragmentContainerVIew (cant inherit, because the one from Jetpack is final.... ) and write a customized set of Transitions that does not use ViewOverlay or use it in consistent manner preserving the z-order.

This actually isnt even funny anymore. It is still broken.

- Cancelling replace-fragment transitions, i.e. navigating up during a transition, causes the pop-exiting fragment to appear below the pop-entering fragment.
- It doesn't work with setExitTransition / setEnterTransition. Entering fragment is below the exiting fragment.

I have no words for this. Ill probably just use multiple-activities (instead of single-activity) and use activity transitions.

If someone has a solution, it will be much appreciated.