We have a significant number of device-specific compatibility issues with the current Android camera implementation; finding and working around each one individually is very time consuming, and requires access to the affected devices. The CameraX API is intended to be a higher-level API that abstracts away most of these differences, so would in theory give us better compatibility and easier maintenance.

Since switching to CameraX is expected to involve a complete rewrite of the Android implementation, we want to use the direct platform API wrapping approach that was recently used in webview_flutter (or, if there are unexpected difficulties with that approach in the context of camera, to lean heavily toward using Dart rather than Java code where possible), since although we haven't had time to fully prove out the benefits of that approach yet, we currently expect it to be the direction we move toward for 1P plugins, so adopting it while we're already doing a rewrite makes sense.

At a high level, the approach would be:

• Write a high-level design document mapping platform interface methods to CameraX implementations. This is to ensure there aren't any obvious functionality mismatches that would prevent adoption of CameraX without plugin-API-level changes, as well as to identify and discuss any open design questions (e.g., should we use PreviewView, which looks like it would require PlatformView? Do we even have the option of continuing to use a direct texture for previewing?)
• Begin implementing a parallel implementation. We should ideally do this with incremental end-to-end feature; e.g., start by implementing availableCameras end to end, and then incrementally add more features. That way we can keep reviews more manageable, and evaluate the new version as we go.
  • There are a few ways we could structure this, but I think the easiest to allow for increment end to end testing is probably to build out an unpublished camera_android_camerax plugin, which we can then test locally by just changing what implementation camera is pointing to. Once it's complete, we can just swap it in for the existing camera_android.
  • Once the design is a little further along, we can expand this list out to a roadmap of incremental features in the order it makes the most sense to add them.

/cc @bparrishMines