[camera_android_camerax] Restore torch state between camera switches

packages/.agents/skills/dart-best-practices/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: dart-best-practices
+description: |-
+  General best practices for Dart development.
+  Covers code style, effective Dart, and language features.
+license: Apache-2.0
+---
+
+# Dart Best Practices
+
+## 1. When to use this skill
+Use this skill when:
+-   Writing or reviewing Dart code.
+-   Looking for guidance on idiomatic Dart usage.
+
+## 2. Best Practices
+
+### Multi-line Strings
+Prefer using multi-line strings (`'''`) over concatenating strings with `+` and
+`\n`, especially for large blocks of text like SQL queries, HTML, or
+PEM-encoded keys. This improves readability and avoids
+`lines_longer_than_80_chars` lint errors by allowing natural line breaks.
+
+**Avoid:**
+```dart
+final pem = '-----BEGIN RSA PRIVATE KEY-----\n' +
+    base64Encode(fullBytes) +
+    '\n-----END RSA PRIVATE KEY-----';
+```
+
+**Prefer:**
+```dart
+final pem = '''
+-----BEGIN RSA PRIVATE KEY-----
+${base64Encode(fullBytes)}
+-----END RSA PRIVATE KEY-----''';
+```
+
+### Line Length
+Avoid lines longer than 80 characters, even in Markdown files and comments.
+This ensures code is readable in split-screen views and on smaller screens
+without horizontal scrolling.
+
+**Prefer:**
+Target 80 characters for wrapping text. Exceptions are allowed for long URLs
+or identifiers that cannot be broken.
+
+## Related Skills
+
+- **[dart-modern-features]**: For idiomatic
+  usage of modern Dart features like Pattern Matching (useful for deep JSON
+  extraction), Records, and Switch Expressions.
+
+[dart-modern-features]: https://github.com/kevmoo/dash_skills/blob/main/.agent/skills/dart-modern-features/SKILL.md

packages/.agents/skills/dart-package-maintenance/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: dart-package-maintenance
+description: |-
+  Guidelines for maintaining external Dart packages, covering versioning,
+  publishing workflows, and pull request management. Use when updating Dart
+  packages, preparing for a release, or managing collaborative changes in a
+  repository.
+---
+
+# Dart Package Maintenance
+
+Guidelines for maintaining Dart packages in alignment with Dart team best
+practices.
+
+## Versioning
+
+### Semantic Versioning
+- **Major**: Breaking changes.
+- **Minor**: New features (non-breaking API changes).
+- **Patch**: Bug fixes, documentation, or non-impacting changes.
+- **Unstable packages**: Use `0.major.minor+patch`.
+- **Recommendation**: Aim for `1.0.0` as soon as the package is stable.
+
+### Pre-Edit Verification
+- **Check Published Versions**: Before modifying `CHANGELOG.md` or
+  `pubspec.yaml`, ALWAYS check the currently released version (e.g., via
+  `git tag` or `pub.dev`).
+- **Do Not Amend Released Versions**: Never add new entries to a version header
+  that corresponds to a released tag.
+- **Increment for New Changes**: If the current version in `pubspec.yaml`
+  matches a released tag, increment the version (e.g., usually to `-wip`) and
+  create a new section in `CHANGELOG.md`.
+
+  - **Consistency**: The `CHANGELOG.md` header must match the new
+    `pubspec.yaml` version.
+
+  - **SemVer Guidelines**:
+    - **Breaking Changes**: Bump Major, reset Minor/Patch
+      (e.g., `2.0.0-wip`, `0.5.0-wip`).
+    - **New Features**: Bump Minor, reset Patch
+      (e.g., `1.1.0-wip`, `0.4.5-wip`).
+    - **Bug Fixes**: Bump Patch (e.g., `1.0.1-wip`).
+
+### Changelog Content
+- **Focus on User Impact**: Entries in `CHANGELOG.md` should focus on changes
+  visible to or impacting the end-user (e.g., new features, bug fixes,
+  breaking changes).
+- **Omit Internal Changes**: Do not include internal refactorings, test
+  changes, or other modifications that do not affect the package's behavior
+  or API for the user.
+
+### Work-in-Progress (WIP) Versions
+- Immediately after a publish, or on the first change after a publish, update
+  `pubspec.yaml` and `CHANGELOG.md` with a `-wip` suffix (e.g., `1.1.0-wip`).
+- This indicates the current state is not yet published.
+
+### Breaking Changes
+- Evaluate the impact on dependent packages and internal projects.
+- Consider running changes through internal presubmits if possible.
+- Prefer incremental rollouts (e.g., new behavior as opt-in) to minimize
+  downstream breakage.
+
+## Publishing Process
+
+1. **Preparation**: Remove the `-wip` suffix from `pubspec.yaml` and
+   `CHANGELOG.md` in a dedicated pull request.
+2. **Execution**: Run `dart pub publish` (or `flutter pub publish`) and resolve
+   all warnings and errors.
+3. **Tagging**: Create and push a git tag for the published version:
+   - For single-package repos: `v1.2.3`
+   - For monorepos: `package_name-v1.2.3`
+   - Example: `git tag v1.2.3 && git push --tags`
+
+## Pull Request Management
+
+- **Commits**: Each PR should generally correspond to a single squashed commit
+  upon merging.
+- **Shared History**: Once a PR is open, avoid force pushing to the branch.
+- **Conflict Resolution**: Prefer merging `main` into the PR branch rather than
+  rebasing to resolve conflicts. This preserves the review history and comments.
+- **Reviewing**: Add comments from the "Files changed" view to batch them.
+- **Local Inspection**: Use `gh pr checkout <number>` to inspect changes
+  locally in your IDE.

packages/.agents/skills/dart-test-fundamentals/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: dart-test-fundamentals
+description: |-
+  Core concepts and best practices for `package:test`.
+  Covers `test`, `group`, lifecycle methods (`setUp`, `tearDown`), and configuration (`dart_test.yaml`).
+license: Apache-2.0
+---
+
+# Dart Test Fundamentals
+
+## When to use this skill
+Use this skill when:
+- Writing new test files.
+- structuring test suites with `group`.
+- Configuring test execution via `dart_test.yaml`.
+- Understanding test lifecycle methods.
+
+## Core Concepts
+
+### 1. Test Structure (`test` and `group`)
+
+- **`test`**: The fundamental unit of testing.
+  ```dart
+  test('description', () {
+    // assertions
+  });
+  ```
+- **`group`**: Used to organize tests into logical blocks.
+  - Groups can be nested.
+  - Descriptions are concatenated (e.g., "Group Description Test Description").
+  - Helps scope `setUp` and `tearDown` calls.
+  - **Naming**: Use `PascalCase` for groups that correspond to a class name
+    (e.g., `group('MyClient', ...)`).
+  - **Avoid Single Groups**: Do not wrap all tests in a file with a single
+    `group` call if it's the only one.
+
+- **Naming Tests**:
+  - Avoid redundant "test" prefixes.
+  - Include the expected behavior or outcome in the description (e.g.,
+    `'throws StateError'` or `'adds API key to URL'`).
+  - Descriptions should read well when concatenated with their group name.
+
+- **Named Parameters Placement**:
+  - For `test` and `group` calls, place named parameters (e.g., `testOn`,
+    `timeout`, `skip`) immediately after the description string, before the
+    callback closure. This improves readability by keeping the test logic last.
+    ```dart
+    test('description', testOn: 'vm', () {
+      // assertions
+    });
+    ```
+
+### 2. Lifecycle Methods (`setUp`, `tearDown`)
+
+- **`setUp`**: Runs *before* every `test` in the current `group` (and nested
+  groups).
+- **`tearDown`**: Runs *after* every `test` in the current `group`.
+- **`setUpAll`**: Runs *once* before any test in the group.
+- **`tearDownAll`**: Runs *once* after all tests in the group.
+
+**Best Practice:**
+- Use `setUp` for resetting state to ensure test isolation.
+- Avoid sharing mutable state between tests without resetting it.
+
+### 3. Configuration (`dart_test.yaml`)
+
+The `dart_test.yaml` file configures the test runner. Common configurations
+include:
+
+#### Platforms
+Define where tests run (vm, chrome, node).
+
+```yaml
+platforms:
+  - vm
+  - chrome
+```
+
+#### Tags
+Categorize tests to run specific subsets.
+
+```yaml
+tags:
+  integration:
+    timeout: 2x
+```
+
+Usage in code:
+```dart
+@Tags(['integration'])
+import 'package:test/test.dart';
+```
+
+Running tags:
+`dart test --tags integration`
+
+#### Timeouts
+Set default timeouts for tests.
+
+```yaml
+timeouts:
+  2x # Double the default timeout
+```
+
+### 4. File Naming
+- Test files **must** end in `_test.dart` to be picked up by the test runner.
+- Place tests in the `test/` directory.
+
+## Common commands
+
+- `dart test`: Run all tests.
+- `dart test test/path/to/file_test.dart`: Run a specific file.
+- `dart test --name "substring"`: Run tests matching a description.
+
+## Related Skills
+
+`dart-test-fundamentals` is the core skill for structuring and configuring
+tests. For writing assertions within those tests, refer to:
+
+- **[dart-matcher-best-practices]**:
+  Use this if the project sticks with the traditional
+  `package:matcher` (`expect` calls).
+- **[dart-checks-migration]**: Use this
+  if the project is migrating to the modern `package:checks` (`check` calls).
+
+[dart-matcher-best-practices]: https://github.com/kevmoo/dash_skills/blob/main/.agent/skills/dart-matcher-best-practices/SKILL.md
+[dart-checks-migration]: https://github.com/kevmoo/dash_skills/blob/main/.agent/skills/dart-checks-migration/SKILL.md

packages/camera/camera_android_camerax/.agents/skills/dart-best-practices

@@ -0,0 +1 @@
+.agents/skills/dart-best-practices/

packages/camera/camera_android_camerax/.agents/skills/dart-package-maintenance

@@ -0,0 +1 @@
+.agents/skills/dart-package-maintenance/

packages/camera/camera_android_camerax/.agents/skills/dart-test-fundamentals

@@ -0,0 +1 @@
+.agents/skills/dart-test-fundamentals/

packages/camera/camera_android_camerax/android/src/main/java/io/flutter/plugins/camerax/CameraInfoProxyApi.java

@@ -61,4 +61,9 @@ public LiveDataProxyApi.LiveDataWrapper getZoomState(CameraInfo pigeonInstance)
     return new LiveDataProxyApi.LiveDataWrapper(
         pigeonInstance.getZoomState(), LiveDataSupportedType.ZOOM_STATE);
   }
+
+  @Override
+  public Boolean hasFlashUnit(CameraInfo pigeonInstance) {
+    return pigeonInstance.hasFlashUnit();
+  }
 }

packages/camera/camera_android_camerax/android/src/main/java/io/flutter/plugins/camerax/CameraXLibrary.g.kt

@@ -1,7 +1,7 @@
 // Copyright 2013 The Flutter Authors
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
-// Autogenerated from Pigeon (v26.1.7), do not edit directly.
+// Autogenerated from Pigeon (v26.1.5), do not edit directly.
 // See also: https://pub.dev/packages/pigeon
 @file:Suppress("UNCHECKED_CAST", "ArrayInDataClass")
 
@@ -1301,7 +1301,7 @@ enum class CameraStateType(val raw: Int) {
   }
 }
 
-/** The types (T) properly wrapped to be used as a LiveData<T>. */
+/** The types (T) properly wrapped to be used as a `LiveData<T>`. */
 enum class LiveDataSupportedType(val raw: Int) {
   CAMERA_STATE(0),
   ZOOM_STATE(1);
@@ -2199,6 +2199,9 @@ abstract class PigeonApiCameraInfo(
       pigeon_instance: androidx.camera.core.CameraInfo
   ): io.flutter.plugins.camerax.LiveDataProxyApi.LiveDataWrapper
 
+  /** Returns true if the camera has a flash unit. */
+  abstract fun hasFlashUnit(pigeon_instance: androidx.camera.core.CameraInfo): Boolean
+
   companion object {
     @Suppress("LocalVariableName")
     fun setUpMessageHandlers(binaryMessenger: BinaryMessenger, api: PigeonApiCameraInfo?) {
@@ -2247,6 +2250,28 @@ abstract class PigeonApiCameraInfo(
           channel.setMessageHandler(null)
         }
       }
+      run {
+        val channel =
+            BasicMessageChannel<Any?>(
+                binaryMessenger,
+                "dev.flutter.pigeon.camera_android_camerax.CameraInfo.hasFlashUnit",
+                codec)
+        if (api != null) {
+          channel.setMessageHandler { message, reply ->
+            val args = message as List<Any?>
+            val pigeon_instanceArg = args[0] as androidx.camera.core.CameraInfo
+            val wrapped: List<Any?> =
+                try {
+                  listOf(api.hasFlashUnit(pigeon_instanceArg))
+                } catch (exception: Throwable) {
+                  CameraXLibraryPigeonUtils.wrapError(exception)
+                }
+            reply.reply(wrapped)
+          }
+        } else {
+          channel.setMessageHandler(null)
+        }
+      }
     }
   }