# Conflicts and Resolution Between LetMagic Beauty SDK and QR Code Scanning on Flutter with Agora Audio & Video SDK When building video social apps with the Flutter tech stack, developers commonly integrate core audio & video calling capabilities alongside value-added modules such as real-time beauty effects and QR code scanning. However, conflicts may arise due to overlapping underlying resources and execution workflows when these modules run concurrently. We recently encountered a typical compatibility issue in a real project: after integrating the Agora Audio & Video SDK, the built-in beauty module clashed with the essential QR code scanning function, resulting in malfunction in specific scenarios. This article shares our troubleshooting process and solutions for reference. ## Problem Phenomenon and Initial Troubleshooting In the early stage of the project, we completed integration of Agora’s audio & video calling framework and successfully accessed a third-party beauty SDK to enable real-time beautification during video calls. The issue emerged after we added the QR code scanning module for friend addition and scene entry. Specific symptoms are as follows: If users enable beauty filters for video preview or calls first, launching the QR code scanning page afterwards will either fail to initialize the camera and show a black screen, or lead to drastically reduced recognition efficiency and total function failure. Conversely, if QR code scanning is used prior to enabling video beauty effects, the beauty features may also fail to load normally. We initially determined that the conflict stemmed from competing access to the shared camera hardware, improper lifecycle management, or conflicting usage of underlying graphics libraries such as OpenGL ES. Both modules attempted to occupy the camera exclusively or interfered with each other’s graphics context and texture processing. ## In-Depth Analysis and Root Cause Identification We conducted isolated tests for further verification: First, we tested three functions separately: pure audio & video calls without beauty effects, camera preview powered solely by the beauty SDK, and standalone QR code scanning. All worked properly on their own, which ruled out basic integration defects within individual modules. Next, we adjusted the execution order of functions and found a clear pattern: the module launched later would malfunction, while the one started earlier ran normally. This indicated that shared resources including the camera and graphics context were not fully released or reset after use, blocking subsequent modules from acquiring resources properly. After reviewing official documents and communicating with relevant technical teams, we pinpointed three major conflict points: 1. **Camera initialization parameters and session management** The beauty SDK and QR code scanning SDK adopt different settings for camera resolution, frame rate and focus mode. Failure to terminate the existing camera session and reset parameters before switching functions will cause initialization failures for the next session. 2. **OpenGL ES environment and texture conflicts** Real-time beauty processing involves intensive GPU operations, which create and manage exclusive EGL contexts, texture units and rendering programs. Most QR code scanning SDKs with advanced image recognition also rely on GPU acceleration. Conflicts in context sharing and texture ID management will trigger abnormal graphics rendering. 3. **Calling sequence of native code and Flutter Platform Channel** In hybrid development, access to native hardware is implemented via asynchronous communication through platform channels. Interleaved calls, callback errors or thread contention between native plugins of the two modules will also cause anomalies. ## Solutions and Implementation Steps Based on the above analysis, we adopted a systematic solution focusing on orderly switching and isolated management of camera and graphics resources between modules. 1. Optimize Camera Lifecycle Management We refactored the global camera management logic. Before any module accesses the camera, the system checks for active camera sessions and forces full resource release, including stopping video streams and destroying camera instances. A brand-new camera session will then be initialized with dedicated parameters for the target module. All startup and destruction logic is executed in corresponding lifecycle hooks such as `initState` and `dispose` of related pages, ensuring complete resource cleanup during page navigation. 2. Isolate Graphics Processing Environments To resolve potential OpenGL ES conflicts, we adjusted the initialization configurations of both SDKs after confirmation with their technical support teams. The LetMagic Beauty SDK is configured to run within an independent self-managed graphics context, preventing its textures and rendering programs from interfering with the Flutter engine or other plugins. Similar isolation is applied to the QR code scanning SDK if supported. In certain cases, we serialized GPU operations to ensure only one module performs sensitive graphics tasks at a time. The graphics context will also be explicitly saved and restored before and after usage. 3. Unify and Coordinate Platform Calls A lightweight coordinator is built on the Flutter layer to arbitrate requests for camera and graphics resources. It maintains a simple state machine to track the current resource occupant. If the QR code scanning function is requested while beauty effects are active, the coordinator will pause the beauty module and release relevant resources first, then initialize the scanner after confirmation. The same logic applies in reverse. This