[camera_android_camerax] Fix video recording after backgrounding app by camsim99 · Pull Request #12145 · flutter/packages

camsim99 · 2026-07-08T17:00:08Z

WIP towards fixing flutter/flutter#183880.

As of now, reviewers focus on issues implemenation_plan.md.

Normal pull request information above the line.

This pull request is an attempt to "oneshot" fixing flutter/flutter#183880. Using antigravity to execute a plan that is collaboratively worked on. The "rules" are to not allow human authored code to camera_android_camerax and to not rely on human code review feedback for code iteration.

We can add documentation, skills, mcp servers, presubmit test etc. Basically any "support infrastructure" for development is allowed but the package changes must be generated as a single pass.
When we discover that the plan is not good enough we will blow the package changes away and either modify the plan or add more support infrastructure and try again.

For more information see the working doc in go/flutter-project-one-shot

Pre-Review Checklist

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

…e harness

camsim99 · 2026-07-08T17:05:33Z

+dart run ../../../script/tool/bin/flutter_plugin_tools.dart integration-test --android --packages=camera_android_camerax
+```
+
+### Manual Verification


In an ideal world, it would know how to launch the emulator and test but I actually don't know if the agent would have any way of interacting with the emulator after that in a meaningful way (even if it were a more minimal app than the example).

Could we do this via an espresso test?

That's a great idea! Yes, definitely.

Well wait a quick search makes it seem like we would need UiAutomator to get real camera recordings. We could mock it but I'll have to look into what that would look like.

Or we could use something like https://pub.dev/packages/flutter_mcp or https://github.com/leancodepl/marionette_mcp

camsim99 · 2026-07-08T17:32:30Z

+    });
+```
+
+## Verification Plan


In our first plan, we had it explicitly list out the steps it would take to make sure that the code is high quality. I'm ok with that not being explicitly included because it will be in our AGENTS.md and the skills, but just noting in case other reviewers do not agree.

for now I think the verification steps should be listed especially if there are no artifacts of that verification.

For a human, this would be something like, I ran it on a pixel device and swapped between front facing and rear facing camera and it the example app did not crash.

camsim99 · 2026-07-08T17:37:25Z

+```
+
+### Manual Verification
+1. Run the example app (`example/lib/main.dart`) on an Android device.


At the very least it can run the example app and see if it builds (or at least try a flutter build apk).

camsim99 · 2026-07-08T18:17:17Z

This might not be the final AGENTS.md we use in the plugin, but included my draft for now in case some of the core information was useful for creating the implementation plan.

#12066 is my actual proposal.

stuartmorgan-g · 2026-07-08T19:12:20Z

+dart run ../../../script/tool/bin/flutter_plugin_tools.dart integration-test --android --packages=camera_android_camerax
+```
+
+### Manual Verification


Could we do this via an espresso test?

stuartmorgan-g · 2026-07-08T19:14:23Z

+dart run ../../../script/tool/bin/flutter_plugin_tools.dart integration-test --android --packages=camera_android_camerax
+```
+
+### Manual Verification


What does it mean for a one-shot plan to have a manual verification step? Does that mean that the reviewer is expected to read and carry out this section as part of the code review?

Yes. In both of our one-shot plan attempts, we did not ask for this section specifically, but I assume it's generated because the agent assumes it can't verify the solution itself. I do wonder if that's true, though. It can definitely launch an emulator and run the app, but I need to verify it could interact with it as we'd expect.

If it is expected to be done by the reviewer we should call the section "reviewer verification" and it should be required to be part of the pull request.

In my experience "manual verification" were steps that did not produce artifacts like automated tests that were done to ensure the code was correct and they were only done once near the end but not after all final edits.

reidbaker · 2026-07-13T20:23:17Z

+   /// Releases the resources of the accessed camera with ID [cameraId].
+   @override
+   Future<void> dispose(int cameraId) async {
+     await preview?.releaseSurfaceProvider();


(this change can be considered out of scope) Do these need to be awaited in order? can we instead record a future for each of them then await the set?

reidbaker · 2026-07-13T20:26:27Z

+     await deviceOrientationManager.stopListeningForDeviceOrientationChange();
+    recording = null;
+    pendingRecording = null;
+    videoOutputPath = null;


Something in the code above stores the video safely when the camera is disposed. Instead of setting these values to null here can we make that code null out the recording?

For example if there is a lifecycle event from the camerax library for native recording stop can we forward that call instead of relying on the dispose? (maybe dispose is the call being forwarded?)

reidbaker · 2026-07-13T20:27:49Z

+```
+
+#### [MODIFY] android_camera_camerax_test.dart
+Add assertions in the `dispose` test to ensure that the recording state variables are properly nullified when `dispose()` completes.


FWIW It feels like a pattern that information about camera is in a bunch of variables that need their state cleared. Is there a better pattern for this that we can use. Maybe a CameraState object that we can call dispose on that handles all its own variables and makes the lifecycle more clear.

reidbaker · 2026-07-13T20:28:26Z

+     verify(mockDeviceOrientationManager
+         .stopListeningForDeviceOrientationChange());
+
+    // Verify state is cleared


can this test also ensure that the video was saved correctly?

reidbaker · 2026-07-13T20:29:44Z

+I will run the following commands:
+```bash
+# Verify the example APK builds successfully without errors
+cd example/android && ./gradlew assembleDebug
+


I dont this is the way we want to verify the android code builds. It should use the flutter tool.

reidbaker · 2026-07-13T20:30:39Z

+dart run ../../../script/tool/bin/flutter_plugin_tools.dart dart-test --packages=camera_android_camerax
+```
+
+### Manual Verification (What requires human interaction/devices)


See comment thread about this being reviewer verification.

camsim99 added 2 commits July 8, 2026 09:46

add draft of AGENTS.md since something like this should be part of th…

8c98295

…e harness

Add first iteration of implementation plan

7874903

github-actions Bot added the p: camera label Jul 8, 2026

camsim99 commented Jul 8, 2026

View reviewed changes

Comment thread packages/camera/camera_android_camerax/implementation_plan.md

stuartmorgan-g reviewed Jul 8, 2026

View reviewed changes

Second iteration

8e6b053

reidbaker reviewed Jul 13, 2026

View reviewed changes

Uh oh!

Conversation

camsim99 commented Jul 8, 2026

Pre-Review Checklist

Footnotes

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

reidbaker Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

reidbaker Jul 13, 2026 •

edited

Loading