feat(shortcuts): support pinned shortcuts from "Add to home screen"

[smrtkrft]

Type of Change

• Feature

---

Pre-Submission Checklist

• No existing Pull Request for this change
• Descriptive commit message
• Self-reviewed the code
• Comments added where necessary
• No new warnings or errors introduced
• Changes made in a separate branch
• Branch named using prefix (e.g., bug/, feat/, clean/, release/)
• All user-facing text supports localization (if applicable)
• Updated documentation or relevant README sections (if applicable)
• Added screenshots or demo for UI changes (if applicable)

---

Before Submitting Your Pull Request

• Clear and descriptive PR title
• Detailed summary of the changes made
• Linked relevant issue(s) using Closes #XXXX or Fixes #XXXX (if applicable)

---

Summary of Changes

Closes #283

As discussed in #283, mLauncher now answers Android's standard "Add to home screen" request (ACTION_CONFIRM_PIN_SHORTCUT), the same API stock launchers use. Browsers and other apps can now add web apps and pinned shortcuts. There is no WebView: the shortcut still opens in the app that created it, through LauncherApps.startShortcut. No new permissions are added. Users who never add a shortcut see no change.

Key Changes

1. Adding shortcuts: the new ui/shortcuts/PinShortcutActivity shows a small dialog where the user can name the shortcut before it is added. The dialog says where the shortcut comes from, e.g. "Web shortcut · Chrome" or "Shortcut · Maps". It uses a translucent theme, so the browser stays visible behind it.
2. Listing and launching: pinned shortcuts are listed as AppListItem, with activityClass = "shortcut:<id>" and activityPackage set to the creating app. This lets home slots, gestures, favorites and the file cache work without changing how items are stored. MainViewModel.launchApp starts them via the new helper/ShortcutHelper, so the lock check still applies.
3. Per-item settings: a shortcut shares its package with the browser, so the new AppListItem.settingsKey (<package>/shortcut:<id> for shortcuts, the package for apps) is used for alias, tag, lock and pin. The behaviour for apps is unchanged. Renaming, hiding, locking or pinning a shortcut never affects the browser, and the reverse holds too.
4. Cleanup: deleting a shortcut from the drawer unpins it. It also removes its alias, tag, lock, pin and hidden entries, clears any home or gesture slot using it, and sets that gesture's action to Disabled. When the creating app removes a shortcut or is uninstalled, a LauncherApps.Callback triggers the same cleanup and the home screen redraws. Cleanup only runs when every profile could be read, so a locked private space never loses settings.
5. Other places: search uses the shortcut's alias; the shortcut's own icon is shown (icons are cached and preloaded for home); the home widget opens the shortcut itself and respects the lock; the home usage-time row is hidden for shortcuts.

---

Test Information

• MultiLauncher Version: 1.12.1 Build 2 (prodDebug)
• Device Name: Android Emulator (sdk_gphone16k_arm64)
• Android Version: 17
• Other Notes:
  • Added shortcuts from Chrome ("Create shortcut", plus "Install" when a WebAPK can't be created), Brave (which can't create WebAPKs) and Google Maps (directions).
  • Tested search, rename, hide/unhide, lock, pin, delete, home and gesture slots, and icons on and off, in both the drawer and on home.
  • Tested cleanup when the creating app's data is cleared, and a locked private space, which leaves settings untouched.
  • Checked that renaming, hiding, locking and pinning normal apps still work as before. Unit tests pass, with no crashes or ANRs.
  • Not tested: WhatsApp, because I had no phone number on the emulator.

---

Screenshots

Add shortcut dialog (on top of Chrome)

App list: shortcut with its own icon

Home screen: shortcut in a home slot

[CreativeCodeCat]

you have done a good job with this and it works just as i would have wanted it to.