Skip to content

NEW: Add LocationSensor for Input System - #2469

Open
MorganHoarau wants to merge 13 commits into
im-parity/stagingfrom
im-parity/isx-2227-location-sensor
Open

NEW: Add LocationSensor for Input System#2469
MorganHoarau wants to merge 13 commits into
im-parity/stagingfrom
im-parity/isx-2227-location-sensor

Conversation

@MorganHoarau

@MorganHoarau MorganHoarau commented Aug 7, 2026

Copy link
Copy Markdown
Collaborator

Description

Addresses ISX-2227 is part of the Input Manager parity epic ISX-2108.

This PR is the managed layer only. Refer to the native bridge PR here.

Add a LocationSensor device that exposes the device's GPS and lifecycle through the standard Input System surface:

  • Readings as event-driven controls: latitude, longitude, altitude, horizontalAccuracy, verticalAccuracy, timestamp.
  • Lifecycle via InputSystem.EnableDevice / DisableDevice + status and isEnabledByUser as query properties.
  • Configure(desiredAccuracyInMeters, updateDistanceInMeters) + ResetConfiguration(), with project defaults InputSettings.locationAccuracy / locationDistanceThreshold (both 10, matching legacy Start()), surfaced in Project Settings.

Backed by the shared native LocationService.

Class diagram: LocationSensor and command surface
classDiagram
    class Sensor
    class LocationSensor {
        +AxisControl latitude
        +AxisControl longitude
        +AxisControl altitude
        +AxisControl horizontalAccuracy
        +AxisControl verticalAccuracy
        +DoubleControl timestamp
        +LocationServiceStatus status
        +bool isEnabledByUser
        +static LocationSensor current
        +Configure(float, float)
        +ResetConfiguration()
    }
    class LocationState {
        <<internal, IInputStateTypeInfo>>
        +double timestamp
        +float latitude
        +float longitude
        +float altitude
        +float horizontalAccuracy
        +float verticalAccuracy
    }
    class InputSettings {
        +float locationAccuracy
        +float locationDistanceThreshold
    }
    class QueryLocationStatusCommand
    class QueryLocationEnabledByUserCommand
    class ConfigureLocationCommand

    Sensor <|-- LocationSensor
    LocationSensor ..> LocationState : stateType
    LocationSensor ..> QueryLocationStatusCommand : status (LSTA)
    LocationSensor ..> QueryLocationEnabledByUserCommand : isEnabledByUser (LUSR)
    LocationSensor ..> ConfigureLocationCommand : Configure (LCFG)
    LocationSensor ..> InputSettings : ResetConfiguration reads defaults
Loading

Documentation Impact

  • Public API added (LocationSensor + controls + status / isEnabledByUser / Configure / ResetConfiguration, InputSettings.locationAccuracy / locationDistanceThreshold, three public command structs). All carry XML docs.
  • Migration table updated: Documentation~/corresponding-old-new-api.md now maps Input.location -> LocationSensor with a usage snippet.

Testing status & QA

Please describe the testing already done by you and what testing you request/recommend QA to execute. If you used or created any testing project please link them here too for QA.

ℹ️ PLEASE READ: Parity testing summary document

  • 6 unit tests added (CoreTests_Devices.cs): reading, status, isEnabledByUser, fallback path (no native impl), Configure, ResetConfiguration.
  • On-device (via the InputFeatureParity Validation project):
    • Tested on Android, iOS and Web (Windows, Mac, Android and iOS) in both input backend "Both" and "Input System (new)".

Overall Product Risks

Please rate the potential complexity and halo effect from low to high for the reviewers. Note down potential risks to specific Editor branches if any.

  • Complexity: 1
    • Additive, self-contained device; fallback to Stopped / false where no native impl exists (editor/desktop), so no regression to existing sensors.
  • Halo Effect: 1
    • Touches shared InputSettings (two new serialized fields + settings UI).

Comments to reviewers

Please describe any additional information such as what to focus on, or historical info for the reviewers.

Checklist

Before review:

  • Changelog entry added.
    • Explains the change in Changed, Fixed, Added sections.
    • For API change contains an example snippet and/or migration example.
    • JIRA ticket linked, example (case %%). If it is a private issue, just add the case ID without a link.
    • Jira port for the next release set as "Resolved".
  • Tests added/changed, if applicable.
    • Functional tests Area_CanDoX, Area_CanDoX_EvenIfYIsTheCase, Area_WhenIDoX_AndYHappens_ThisIsTheResult.
    • Performance tests.
    • Integration tests.
  • Docs for new/changed API's.
    • Xmldoc cross references are set correctly.
    • Added explanation how the API works.
    • Usage code examples added.
    • The manual is updated, if needed.

During merge:

  • Commit message for squash-merge is prefixed with one of the list:
    • NEW: ___.
    • FIX: ___.
    • DOCS: ___.
    • CHANGE: ___.
    • RELEASE: 1.1.0-preview.3.

@MorganHoarau MorganHoarau changed the title [DRAFT] Im parity/isx 2227 location sensor NEW: Add LocationSensor for Input System Aug 11, 2026
Comment thread Packages/com.unity.inputsystem/InputSystem/Runtime/Devices/Sensor.cs Outdated
@MorganHoarau
MorganHoarau marked this pull request as ready for review August 11, 2026 15:39

@u-pr u-pr Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Harness Review

LGTM

The new sensor implementation generally aligns with surrounding sensor, command, and settings patterns, while the associated migration guidance needs correction.

Reviewed commit 4c9aef3

🤖 Helpful? 👍/👎

Comment thread Packages/com.unity.inputsystem/Documentation~/corresponding-old-new-api.md Outdated
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant