Add scenario switcher for v4.1

[vibhor1102]

📝 Description

Important

Target release: v4.1. This feature is not intended for v4.0.0.

This PR implements the manual Smart-scenario switching flow discussed and agreed upon in Discussion #921.

It allows a running Smart AutoClicker service to load another Smart scenario without stopping the service, closing the overlay, or requesting screen-capture permission again. The existing media-projection session is kept alive, while the actual scenario change is restricted to the paused/recording state so actions cannot continue running during the transition.

The implementation follows the compromise established in the discussion:

• the service notification is the generally available entry point;
• the floating-toolbar button is optional and disabled by default;
• enabling the toolbar entry is intended for users who switch scenarios frequently;
• this remains a manual user action and is separate from automated scenario chaining.

✨ User-facing changes

Switch from the service notification

The expanded Smart-scenario notification now includes a Switch action using the Material Symbols swap_horiz icon.

If detection is active when the action is tapped, the service first pauses detection and waits for the processor to reach its stable recording state. It then opens the scenario picker as an overlay, keeping the automated app in the foreground and preserving the current capture session.

Repeated notification taps cannot open multiple pickers while that pause is settling.

Optional floating-toolbar entry

Settings now contains a Show scenario switcher toggle, described as: “Shows the scenario switcher in the floating toolbar for quick swaps.”

When enabled, the toolbar button:

• is visible only for a paused Smart scenario with a live media projection;
• uses the same button structure, tint, sizing, and conventions as the existing toolbar actions;
• uses the Material Symbols swap_horiz asset at the requested weight;
• is placed in the toolbar before it is shown, avoiding the delayed one-slot expansion seen in the earlier implementation.

The notification entry remains available regardless of this preference.

Compact scenario picker

The picker follows the home page’s card-based visual language while deliberately removing home-page functionality that is not useful during a quick switch:

• the active scenario is shown as a restrained toolbar subtitle;
• the subtitle grows up to 14sp when space permits, shrinks to a legible 12sp for longer names, and only then ellipsizes;
• only alternative Smart scenarios are selectable;
• cards show the Smart icon and scenario name, with no expansion, statistics, management actions, or secondary metadata;
• cards can grow vertically for wrapped names and use 8dp inner vertical padding;
• portrait uses one column, while landscape uses two columns to avoid showing only a few oversized rows;
• the selected home-page scenario order is applied automatically, without duplicating sorting controls inside the picker;
• loading, empty, switching, retry, and state-specific error feedback are included;
• selection is disabled while a switch is in progress, with progress shown only on the selected row.

The picker stays in the smart-config feature rather than directly importing the home-page adapter from the application module. Direct reuse would reverse the existing module dependency and create a cycle, while the home adapter also carries expansion, statistics, event previews, and scenario-management actions that this flow intentionally does not need. The smaller feature-local component instead reuses the relevant theme, card, typography, icon, and sorting conventions.

🛡️ Switching and service-state safety

Scenario changes are coordinated by a dedicated SmartScenarioSwitcher rather than being performed directly by the dialog.

The switching path:

1. captures the current service-session identifier;
2. confirms that a Smart service, scenario, and live recording projection are still available;
3. rejects switching while detection is active or the processor is in another invalid state;
4. reloads the selected scenario from the database instead of trusting a potentially stale UI object;
5. revalidates the service session and projection after that suspending database lookup;
6. serializes the switch against another switch and against detection starting;
7. saves the new scenario and records exactly one usage event;
8. updates service-facing state, the foreground notification, and the quick-settings tile;
9. closes the picker only after a successful switch.

If the service stops, restarts, loses projection, changes processing state, or the selected scenario is deleted during the operation, the stale transition is rejected and the current service session is not overwritten. Persistence and UI-synchronization failures are reported without treating an uncommitted switch as successful.

The dialog maps these outcomes to specific localized messages and offers a retry when the selected scenario is still available.

↕️ Shared sorting and usage statistics

The home page and scenario picker now use the same generic sorting helper for name, most-recently-used, and most-used ordering. Stable name and database-ID tie-breakers prevent equal values from making the list jump unpredictably.

A scenario selected through the switcher counts as a use, just like a scenario started normally. Database migration 23 → 24 makes the usage relationship truly one-to-one:

• existing duplicate rows are merged deterministically;
• start counts are summed;
• the newest last-used timestamp is kept;
• a unique index prevents future racing updates from recreating duplicates.

This is required so quick switches remain accurately represented by the existing home-page sorting preferences.

🌍 Localization

All 17 user-facing strings introduced by the feature are translated for the ten locale sets currently shipped by the project:

• Arabic
• Spanish
• French
• Italian
• Japanese
• Brazilian Portuguese
• Russian
• Ukrainian
• Simplified Chinese
• Traditional Chinese

The translations follow existing project terminology where equivalent wording was already present.

🚫 Deliberate non-goals

• No automated scenario chaining or conditional switching.
• No switching of Dumb scenarios.
• No scenario creation, editing, deletion, import/export, or card expansion from the picker.
• No independent sorting or filtering controls in the picker.
• No new media-projection request during a valid running session.
• No always-visible fifth floating-toolbar action for users who leave the setting disabled.

✅ How to test

Notification flow

1. Start a Smart scenario and begin detection.
2. Expand the service notification and tap Switch.
3. Confirm that detection pauses and one scenario picker opens.
4. Select another scenario.
5. Confirm that the picker closes, the new scenario is loaded, capture permission is not requested again, and notification/tile information reflects the selected scenario.

Floating-toolbar flow

1. Enable Settings → Show scenario switcher.
2. Start a Smart scenario and pause detection.
3. Confirm that the horizontal swap button is already present when the toolbar first appears, with no delayed width expansion.
4. Switch to another scenario and confirm that the remaining toolbar actions stay responsive.
5. Disable the setting and confirm that the optional toolbar action is absent in the next service session while notification switching still works.

Picker and failure states

1. Check the picker with short and long scenario names in portrait and landscape.
2. Check both light and dark themes and a different display/font scale where possible.
3. Confirm that the current scenario is excluded from the selectable cards.
4. Confirm that the ordering follows the home-page sort preference.
5. Try opening the picker with no alternative Smart scenario and confirm the empty state.
6. Stop the service or remove projection during the picker flow and confirm that the switch is rejected cleanly.

🔍 Validation

• Hosted arm64 debug APK compilation passed.
• The workflow verified the debug package and native ABI.
• Hosted unit tests passed for the shared sorting model, database migration, usage updates, picker ViewModel, and switch coordinator.
• The separate debug application was exercised on an Android 14 device for notification actions, floating-toolbar behavior, scenario switching, responsive layout, and error recovery.

Build and unit-test evidence: https://github.com/vibhor1102/Smart-AutoClicker/actions/runs/32142234934

❓ FAQ

Why is this targeted at v4.1 instead of v4.0.0?

The notification-first flow plus optional floating-toolbar entry is the compromise approved in Discussion #921 for the v4.1 scope. This PR intentionally identifies that target rather than presenting the feature as a late addition to v4.0.0.

Why is the notification action available by default, but the toolbar button optional?

The notification provides scenario switching without permanently adding complexity to the app’s most frequently used overlay. Users who need faster repeated access can opt into the fifth toolbar action.

Why must detection be paused before the scenario is changed?

Switching the processor’s scenario while events and actions are actively running would make the transition ambiguous and unsafe. The notification action pauses first; the toolbar action appears only in the stable paused state.

Does switching request screen-capture permission again?

No. A valid switch keeps the existing media projection alive. If that projection has already been lost, the switch is rejected and the user is told to restart recording instead of silently creating a broken session.

Why not reuse the complete home-page scenario adapter?

The home page belongs to the application module, which already depends on the feature module containing this overlay. Depending on it in the opposite direction would create a module cycle. Its adapter also owns expansion, previews, statistics, and management actions that are deliberately excluded here. The picker therefore uses a compact feature-local card component while sharing the applicable presentation and sorting conventions.

Why are there no sorting controls in the picker?

The picker is meant to be a quick action, not another scenario-management screen. It automatically follows the user’s saved home-page ordering, so adding another set of controls would be redundant and could make the two lists disagree.

Why does this PR include a database migration?

Both normal starts and quick switches update usage statistics. The old non-unique index allowed concurrent updates to create more than one usage row for a scenario. Migration 24 merges any existing duplicates and enforces the intended one-row-per-scenario relationship.

What happens if the service changes while the picker is open?

The switch coordinator checks the service session, processor state, projection, current scenario, and selected database record both before and after suspending work. A stale picker cannot install a scenario into a newly started or torn-down service session.

Does this implement automated scenario chaining?

No. Every switch in this PR is initiated manually by the user. Automated transitions remain a separate feature and design discussion.