Nativephp Launcher Laravel Package

Technical Evaluation

Architecture fit. v0.1.0 is not a PHP package in any meaningful sense: the surface area (Launcher::apps(), Launcher::open($package, $display, $activity), Launcher::isDefaultHome(), Launcher::currentHome(), Launcher::openHomeSettings()) and the HomeRequested($displayId) event are Android platform bindings, and the feature set is kiosk/home-screen enablement on multi-display devices. There is no HTTP layer, no service provider, no config, no Composer metadata, and no PHP runtime path described. For a Laravel/PHP codebase the architectural fit is therefore indirect at best: the package belongs to a companion Android client, and Laravel can only participate as a control plane (device registry, app/display catalogue, policy, telemetry) behind a bridge. Treat the current "Laravel/PHP package" framing as unvalidated.

Integration feasibility. Direct in-process integration is not feasible — PHP cannot answer HOME/SECONDARY_HOME intents, join the home task, or enumerate activities on a display. Feasible patterns are (a) Laravel exposes a signed API that the Android host app consumes, with the Android package owning all launcher behaviour; (b) Laravel dispatches commands over a queue/websocket to a device agent; (c) a thin PHP client wrapping that API for server-side orchestration. Any of these is viable, but none is delivered by v0.1.0.

Technical risk. High. The release is explicitly Android-only, so iOS and web are out of scope from day one. It is verified on exactly two devices (AYN Thor, Android 13; AYANEO, Android 11), which is thin coverage for OEM-variant launcher/role-management behaviour — default-home resolution and secondary-display home handling differ across vendors and Android versions. Making an app the home screen is a privileged, user-visible, hard-to-reverse configuration; misconfiguration can leave a device without a usable launcher. The HomeRequested → Screens::show() coupling introduces a cross-plugin dependency (screens plugin) that must be version-pinned. Version 0.1.0 signals pre-stability: no deprecation policy, no compatibility matrix, no upgrade guarantees.

Key questions.

• Is this actually a Laravel/PHP package, or an Android (Kotlin/Java) library or Flutter plugin that has been mislabelled? Who is the intended consumer?
• What is the supported contract for the Laravel side — REST/JSON schema, auth model, event delivery, idempotency?
• How is IsHomeScreen BACK-at-root behaviour expected to interact with Laravel-driven navigation or kiosk policy?
• Which Android versions and OEMs are targeted beyond the two verified devices? Is there a test matrix commitment?
• What is the exit path if a device is left without a functioning home screen (recovery, ADB, remote unenrol)?
• Is there a roadmap item for non-Android platforms, or is multi-platform permanently out of scope?

Integration Approach

Stack fit. Assume a two-tier design: a Laravel application (API + admin UI + queue workers) and an Android host app embedding this package. Laravel owns identity, device/display inventory, app catalogue, and audit; the Android package owns role requests, home-task residency, and display routing. The PHP-side surface should be a small, versioned client (LauncherClient) that mirrors the native calls as commands — not a reimplementation.

Migration path. No prior assessment exists, so there is nothing to migrate from; the practical path is a spike, not a rollout. Sequence: (1) confirm the package's actual platform and language; (2) build a throwaway Laravel endpoint plus a single-device Android proof on the AYN Thor; (3) validate default-home acquisition, HomeRequested handling, and BACK-at-root; (4) only then design the production API contract. Do not plan a Laravel-side refactor around this release.

Compatibility. PHP/Laravel version compatibility is unknown and effectively undefined by this release. The Android side requires API levels consistent with Android 11+ behaviour and multi-display APIs; SECONDARY_HOME handling is sensitive to OEM customisation. Pin the package exactly (0.1.0), pin the screens plugin, and gate adoption behind device-model allowlisting rather than a version range.

Sequencing. Ship in this order: device allowlist and enrolment → read-only calls (apps(), currentHome(), isDefaultHome()) → openHomeSettings() behind a manual-confirm step → default-home acquisition on a pilot fleet → open() and multi-display routing last. Keep HomeRequested consumption on-device initially; add Laravel-side observability only after the event payload and delivery semantics are stable.

Operational Impact

Maintenance. Expect churn. A 0.1.0 Android package tied to OEM launcher behaviour will need frequent pinning and re-verification; each Android release or OEM skin update is a potential regression. Budget for a device lab (at minimum the two verified models plus one Samsung and one generic AOSP device) and for owning the bridge layer, which is not provided.

Support. Failure modes are user-visible and severe: device boots to no launcher, recents behaviour surprises users (the package deliberately hides the app from recents, which will generate "where did my app go" tickets), and display routing silently falls back to the wrong home. Support runbooks need an unenrol/recovery procedure, and tier-1 staff need device-side diagnostics since Laravel logs will not see on-device failures. Escalation to the package maintainer is single-vendor, pre-1.0, and unproven.

Scaling. The Laravel side scales conventionally (stateless API, queued command dispatch). The real scaling constraint is device count times manual verification effort: every new model or Android version adds qualification cost, and the two-device verification base does not extrapolate. Multi-display fleets multiply configuration surface per device.

Failure modes. (1) Default-home role lost after OS update or user action → app never receives HOME. (2) HomeRequested fires with no responder if the screens plugin is absent or mismatched → blank display. (3) open() targets a missing package/activity → silent no-op or crash loop. (4) Home-task residency interferes with back-stack expectations in other apps. (5) Bridge/network partition leaves Laravel and device state divergent with no reconciliation described in this release.

Ramp-up. Assume days, not hours, for a competent Android engineer, plus Laravel time for the bridge; the API surface is small and readable. The dominant ramp-up cost is organisational: establishing what this package is, who owns the Android host, and how device qualification is funded. Until the platform question is answered, treat v0.1.0 as a feasibility signal and not an adoptable dependency.