Rollback changes in version 5.1.1 (#1807)

Declare FOREGROUND_SERVICE_LOCATION in the plugin manifest, fix permi…

…ssion docs (#1802)

* Declare FOREGROUND_SERVICE_LOCATION in the plugin manifest, fix permission docs

The plugin runs a foreground service with foregroundServiceType="location"
but never declared the FOREGROUND_SERVICE_LOCATION permission itself,
required since Android 14 (API 34) for that service type to start. Apps
had to add it manually; declaring it in the plugin's own manifest lets
the Android manifest merger add it automatically, like the other
geolocator permissions.

Also updates the README:
- Clarifies that ACCESS_FINE_LOCATION should be requested alongside
  ACCESS_COARSE_LOCATION, not as an either/or choice: since Android 12,
  a user can silently downgrade a FINE-only request to approximate
  location, so both should be requested together.
- Fixes the FOREGROUND_SERVICE_LOCATION snippet, which had a stray
  dangling link and a non-self-closing XML tag.

Fixes #1198
Fixes #1474

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* Fix geolocator/example Android build: pin Kotlin Gradle plugin

Same root cause CI just hit in geolocator_android/example, fixed there
in b357b0d: no org.jetbrains.kotlin.android plugin was pinned, so
Flutter's flutter-gradle-plugin falls back to a default Kotlin version
(2.2.10) below its own minimum (2.2.20) on Flutter stable-3.47.5.
Pins the same versions (Kotlin 2.4.0, AGP 9.1.0) already proven to
build in the sibling example.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* Bump geolocator/example Gradle wrapper to 9.3.1

AGP 9.1.0 (just pinned in the previous commit) requires Gradle >=9.3.1;
the wrapper was still on 9.1.0. Matches geolocator_android/example's
wrapper version.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

Declare FOREGROUND_SERVICE_LOCATION in the plugin manifest, fix permi…

…ssion docs (#1802)

* Declare FOREGROUND_SERVICE_LOCATION in the plugin manifest, fix permission docs

The plugin runs a foreground service with foregroundServiceType="location"
but never declared the FOREGROUND_SERVICE_LOCATION permission itself,
required since Android 14 (API 34) for that service type to start. Apps
had to add it manually; declaring it in the plugin's own manifest lets
the Android manifest merger add it automatically, like the other
geolocator permissions.

Also updates the README:
- Clarifies that ACCESS_FINE_LOCATION should be requested alongside
  ACCESS_COARSE_LOCATION, not as an either/or choice: since Android 12,
  a user can silently downgrade a FINE-only request to approximate
  location, so both should be requested together.
- Fixes the FOREGROUND_SERVICE_LOCATION snippet, which had a stray
  dangling link and a non-self-closing XML tag.

Fixes #1198
Fixes #1474

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* Fix geolocator/example Android build: pin Kotlin Gradle plugin

Same root cause CI just hit in geolocator_android/example, fixed there
in b357b0d: no org.jetbrains.kotlin.android plugin was pinned, so
Flutter's flutter-gradle-plugin falls back to a default Kotlin version
(2.2.10) below its own minimum (2.2.20) on Flutter stable-3.47.5.
Pins the same versions (Kotlin 2.4.0, AGP 9.1.0) already proven to
build in the sibling example.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* Bump geolocator/example Gradle wrapper to 9.3.1

AGP 9.1.0 (just pinned in the previous commit) requires Gradle >=9.3.1;
the wrapper was still on 9.1.0. Matches geolocator_android/example's
wrapper version.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

feat: bump dependencies for vertical speed support (#1801)

Bump geolocator_platform_interface to ^4.4.0 and geolocator_android
to ^5.1.0 to support vertical speed and vertical speed accuracy.

Depends on:
- geolocator_platform_interface v4.4.0 (PR #1799)
- geolocator_android v5.1.0 (PR #1800)

Co-authored-by: Maurits van Beusekom <maurits@baseflow.com>

feat(platform-interface): support verticalSpeed and verticalSpeedAccu…

…racy in Position (#1799)

Position gains verticalSpeed, verticalSpeedAccuracy, hasVerticalSpeed, and
hasVerticalSpeedAccuracy.

A platform or service reporting vertical speed (climb/descent rate, e.g. from
GNSS vertical velocity, flight instruments, or aviation sensors) can supply
vertical_speed and vertical_speed_accuracy over the platform channel. fromMap
substitutes 0.0 when missing and records measurement presence via hasVerticalSpeed
and hasVerticalSpeedAccuracy.

The numeric values default to 0.0 and flags default to false, so existing code
compiles and behaves as before without breaking changes. toJson emits the fields
and flags, and fromMap prefers explicit has_* keys when available to survive round
trips.

feat(android): forward optional vertical speed location extras (#1800)

* feat(android): extract vertical speed from FusedLocationProvider extras

Add verticalSpeed and verticalSpeedAccuracy extraction from Android
location extras in LocationMapper, with safe Float/Double casting,
NaN/Infinity rejection, negative accuracy filtering, and multi-key
fallback.

Update AndroidPosition to forward all has*/verticalSpeed fields to
the platform interface Position superclass.

Changes:
- LocationMapper.java: add getDoubleExtra() safe extraction method
- NmeaClient.java: add vertical speed keys to NMEA extras
- LocationMapperTest.java: Java unit tests (new file)
- android_position.dart: forward has* flags and vertical speed
- geolocator_android_test.dart: Dart tests for AndroidPosition

Depends on: geolocator_platform_interface v4.4.0 (PR #1799)

* fix(android): align vertical speed mapper test and clarify source

* fix(android): compile mapper and expose speed availability in example

* test(android): verify optional vertical speed mapping on device

Updates Android Gradle Plugin to 9.3.1

feat(platform-interface): distinguish an unmeasured value from a meas…

…ured 0.0 (#1793)

Position gains hasAccuracy, hasAltitude, hasAltitudeAccuracy, hasHeading,
hasHeadingAccuracy, hasSpeed and hasSpeedAccuracy.

LocationMapper.toHashMap on Android already guards every optional field with
the platform's own predicate and omits the key when it is false, so the
absence arrives at the platform interface correctly expressed. fromMap then
substituted 0.0 for the missing value via _toDouble, and the distinction was
lost. These flags record what the map actually carried.

The numeric values are unchanged and every flag defaults to false, so
existing code compiles and behaves as before. toJson emits the flags and
fromMap prefers them over key presence, so a round trip does not resurrect a
measurement that never happened.

Resolves #1733 and #1525.

Maintenance, updates dependencies

Maintenance, updates dependencies