Improve SettingsTransitionActivity for standalone usage.

- Allow subclass to override when the transition should be enabled,
because we may not want to enable it on other form factors, e.g. on
wear.

- Retrieve the Toolbar instance by overriding setActionBar() which
should be called by any activity using Toolbar as its action bar. Even
if there's any activity not using Toolbar as action bar, it won't
behave well with our transition anyway.

- Refactored ActivityOptions Bundle creation logic to simplify the
code. I did the refactoring originally for sharing it with a new
SettingsTransitionFragment, but then realized doing it in fragment
would be very tedious and unreliable. Still the refactoring looks a
good simplification to me.

- Don't override onOptionsItemSelected() in SettingsTransitionActivity
because different form factors might be expecting different behaviors
for the home/up indicator on Toolbar, e.g. we might expand/collapse a
drawer or do something else instead of finishing the current activity
on Tablet.

    The original implementation that calls onBackPressed() is also
technically incorrect because pressing up is a different action. The
reason the original implementation did so is probably for enabling
transition upon activity finish, but that should actually be done by
calling finishAfterTransition(), so I've fixed the
CollapsingToolbarBaseActivity to call finishAfterTransition() instead
of finish(). This shouldn't bring any regression to existing users of
SettingsTransitionActivity as well because currently the only user of
it is CollapsingToolbarBaseActivity.

Bug: 177638625
Test: manually on R and S platforms
Change-Id: I3c5955db3753f00604b625bd21bf7e78f237ec15

0 files changed, 0 insertions, 0 deletions