Fix #1564 - Launcher shortcuts crash and ignore destination#1565
Conversation
MySearchStopsFragment and MySearchRoutesFragment returned null from onCreateView when the container was null, but ViewPager2's FragmentStateAdapter (introduced by the recent Toolbar/edge-to-edge migration) hosts fragments headlessly and always passes null. The base class then crashed in onActivityCreated with "Content view not yet created" when launching MyStopsActivity or MyRoutesActivity from a pinned launcher shortcut. Inflate the layout against the container with attachToRoot=false, which is the canonical fragment pattern and tolerates either null or a real parent ViewGroup. Also switch shortcut intents from FLAG_ACTIVITY_CLEAR_TOP to FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_CLEAR_TASK so tapping a shortcut while the app is backgrounded opens the shortcut's destination instead of resuming the app's last screen. Adds instrumented regression tests for both fixes.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThis PR fixes issue ChangesFragment Shortcut Launch Fix
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Fixes #1564. Two distinct bugs in the launcher-shortcut path, with the same root cause area but different mechanisms:
MySearchStopsFragmentandMySearchRoutesFragmentreturnednullfromonCreateViewwhen the container was null. ViewPager2'sFragmentStateAdapter(introduced by the recent Toolbar/edge-to-edge migration in commitsd550495a/999ff8ad) hosts fragments headlessly and always passes a null container, soMySearchFragmentBase.onActivityCreatedthen crashed atgetListView()withIllegalStateException: Content view not yet created. Fixed by inflating against the (possibly-null) container withattachToRoot=false— the canonical fragment idiom that works for both headless and rooted hosts.UIUtils.makeShortcutInfowas setting onlyFLAG_ACTIVITY_CLEAR_TOP(from the old Stop shortcuts don't always go directly to ArrivalsListActivity #626 fix), so tapping a shortcut while the app was backgrounded just resumed the app's last screen. Switched toFLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_CLEAR_TASK, the documented pattern for launcher shortcuts.Adds instrumented regression tests for both fixes.
Test plan
./gradlew test connectedObaGoogleDebugAndroidTest— all 223 tests pass.Notes for reviewers
NEW_TASK | CLEAR_TASKchange. The crash fix takes effect immediately for everyone, since the old shortcuts still target the same activity classes.inflate(layout, root, false)(vs. the oldinflate(layout, null)) means the inflated view now receivesLayoutParamsgenerated from the root when one is present. Both affected layouts (my_search_stop_list.xml,my_search_route_list.xml) already declarefill_parentxfill_parent, and the fragment is always re-parented by the host, so this is equivalent in practice.🤖 Generated with Claude Code
Summary by CodeRabbit
Tests
Bug Fixes