diff --git a/__e2e__/flows/feed-reorder.yml b/__e2e__/flows/feed-reorder.yml
index 8d39f1e692..1e2fe70d62 100644
--- a/__e2e__/flows/feed-reorder.yml
+++ b/__e2e__/flows/feed-reorder.yml
@@ -103,6 +103,13 @@ appId: xyz.blueskyweb.app
           id: "editFeedsBtn"
       - assertVisible: "Following"
       - assertVisible: "alice-favs"
+      # Two back presses to reach Home: the first pops the saved-feeds editor
+      # back to the Feeds screen, the second pops Feeds back to Home. On iOS the
+      # equivalent path saves changes first (saveChangesBtn calls
+      # navigation.goBack), so a single "Go back" there already lands on Home.
+      # This Android smoke branch never saves, so it needs the extra pop to
+      # leave the screen state on Home, which the shared steps below expect.
+      - tapOn: "Go back"
       - tapOn: "Go back"
 
 # Remove following
diff --git a/__e2e__/flows/onboarding-avatar-creator.yml b/__e2e__/flows/onboarding-avatar-creator.yml
index de5fb54ccd..7b65c405bb 100644
--- a/__e2e__/flows/onboarding-avatar-creator.yml
+++ b/__e2e__/flows/onboarding-avatar-creator.yml
@@ -15,14 +15,24 @@ appId: xyz.blueskyweb.app
 - tapOn:
     id: "e2eStartOnboarding"
 - tapOn: "Open avatar creator"
-# The avatar-creator bottom sheet opens as a sliver on the short E2E emulator
-# (720x1600), so the picker content sits below the fold. Scroll it into view
-# instead of just waiting. No-op on iOS, where it is already visible.
-- scrollUntilVisible:
-    element:
-      text: "Select an emoji"
-    direction: DOWN
-    timeout: 15000
+# The avatar-creator bottom sheet (Dialog.Inner, non-scrollable) opens only
+# half-expanded on the short E2E emulator (720x1600), a ~220px sliver with the
+# emoji grid below the fold. It is NOT a scroll view, so scrollUntilVisible's
+# swipe grabs the sheet's own drag gesture and flings it closed. Instead, drag
+# the sheet upward to expand it to full height, which brings the picker into
+# view. iOS opens the sheet fully already, so this is Android-only.
+- runFlow:
+    when:
+      platform: Android
+    commands:
+      - swipe:
+          label: "Drag the bottom sheet up to expand it"
+          start: "50%, 90%"
+          end: "50%, 20%"
+          duration: 600
+      - extendedWaitUntil:
+          visible: "Select an emoji"
+          timeout: 10000
 - tapOn: "Select the zap emoji as your avatar"
 - tapOn:
     label: "Tap on yellow"
@@ -30,6 +40,20 @@ appId: xyz.blueskyweb.app
 - tapOn: "Done"
 - waitForAnimationToEnd
 - tapOn: "Select an avatar"
+# Reopening the creator sheet lands on the same half-expanded sliver on
+# Android, so expand it again before reaching for the emoji grid. No-op on iOS.
+- runFlow:
+    when:
+      platform: Android
+    commands:
+      - swipe:
+          label: "Drag the bottom sheet up to expand it"
+          start: "50%, 90%"
+          end: "50%, 20%"
+          duration: 600
+      - extendedWaitUntil:
+          visible: "Select an emoji"
+          timeout: 10000
 - tapOn: "Select the atom emoji as your avatar"
 - tapOn: "Done"
 - waitForAnimationToEnd
diff --git a/__e2e__/flows/thread-muting.yml b/__e2e__/flows/thread-muting.yml
index 070c971982..cd9c156662 100644
--- a/__e2e__/flows/thread-muting.yml
+++ b/__e2e__/flows/thread-muting.yml
@@ -81,8 +81,16 @@ appId: xyz.blueskyweb.app
     id: "bottomBarProfileBtn"
 - tapOn:
     id: "profilePager-selector-1"
+# Both replies target the thread root ("Test thread" by alice), which sits at
+# the top of bob's Replies tab. That tab renders each post in the thread with
+# its own replyBtn, so scope the tap to the root post's card
+# (feedItem-by-alice.test) rather than relying on which replyBtn Maestro picks
+# first. This keeps both reply taps deterministic regardless of list order or
+# how many posts have rendered.
 - tapOn:
     id: "replyBtn"
+    childOf:
+      id: "feedItem-by-alice.test"
 # Wait for the composer to fully open before typing.
 - extendedWaitUntil:
     visible:
@@ -92,14 +100,20 @@ appId: xyz.blueskyweb.app
 - tapOn:
     id: "composerPublishBtn"
 # Wait for the composer to close and the thread reply button to return before
-# opening the composer again. Previously this raced and the second replyBtn tap
-# landed before the composer was ready, so the composer never opened.
+# opening the composer again. The replyBtn is effectively always present on this
+# screen, so waiting on its visibility alone does not gate on the composer close
+# animation or the author-feed re-render that follows a post. Without letting
+# those settle, the next replyBtn tap fires mid-transition and is swallowed, so
+# the composer never opens. Wait for the button, then for animations to end.
 - extendedWaitUntil:
     visible:
       id: "replyBtn"
     timeout: 10000
+- waitForAnimationToEnd
 - tapOn:
     id: "replyBtn"
+    childOf:
+      id: "feedItem-by-alice.test"
 # Wait for the composer to fully open before typing.
 - extendedWaitUntil:
     visible: