Enable OpenGL tracing on Android: why you need it and how to configure it correctly

Have you ever encountered a situation where a game or app on Android suddenly starts to slow down, display artifacts, or even crashes with an error GL_OUT_OF_MEMORY? In 90% of such cases, problems with graphic rendering are to blame - or more precisely, with the operation of the standard API for 2D/3D graphics on mobile devices. This is where OpenGL ES, a standard API for 2D/3D graphics on mobile devices. This is where it comes to the rescue OpenGL tracing comes to the rescue - a tool that allows you to “peep” at what commands the application sends to the GPU and identify bottlenecks.

But what is tracing in practice? Imagine that your application is a cook, and OpenGL is a stove. The tracing seems to turn on a camera above the stove and record every step: how much oil is poured, at what temperature the dish is fried, whether the food is burning. Only instead of oil and temperature, function calls like glDrawArrays, texture transfer or shader changes are recorded. These logs help you find why the “dish” (your graphics) turns out to be spoiled.

In this article we will look at:

• 🔍 What is OpenGL tracing and what problems it solves (from bugs in games to performance optimization).
• ⚙️ How to enable tracing on any Android device - from root methods to ADB tools.
• 📊 How to read and analyze logsto find the root of the problem.
• ⚠️ Risks and limitations: why tracing itself can cause lags and how to avoid it.

What is OpenGL tracing and why do you need it

Tracing (or tracing) OpenGL ES is the process of recording all the commands that the application sends to the graphics driver. These commands include:

• 🎨 Calling rendering functions (glDrawElements, glClear).
• 🖼️ Loading textures and shaders (glTexImage2D, glShaderSource).
• 🔄 Changes of states (changing buffers, setting blending).
• 🚨 Driver errors (for example, GL_INVALID_OPERATION).

Main scenarios where tracing is indispensable:

1. Debugging graphics artifacts: if “torn” textures, flickering objects or incorrect colors appear in the game, the logs will show which command did not work correctly.
2. Performance optimization: Tracing identifies redundant calls (such as loading the same textures over and over) or rendering bottlenecks.
3. Compatibility analysis: helps you understand why an application works on one device (for example Samsung Galaxy S23), but crashes on another (Xiaomi Redmi Note 10).

It is important to understand that tracing is not a profiler (like Android GPU Inspector). It does not show FPS or GPU load, but only records sequence of commands and their parameters. This is like the difference between video recording of an operation (tracing) and measuring its duration (profiling).

⚠️ Attention: On some devices (especially those with processors Mediatek or outdated drivers), tracing may lead to additional lags or even application crash. This is due to implementation features OpenGL ES manufacturer.

Ways to enable OpenGL tracing on Android

There are several methods for activating tracing, and their choice depends on your goals and level of access to the device:

Let's consider each method in more detail.

Method 1: Enabling via ADB (without root)

The most universal method that works on any device with USB debugging enabled. You will need:

• 📱 Android device with the unlocked option USB debugging (in Settings → For developers).
• 💻 Computer with installed ADB drivers and utility adb (included with Android SDK).

Steps:

1. Connect the device to the PC and run the command:

   adb shell setprop debug.gl.trace 1

   This will enable tracing for all applications.

2. To trace a specific application (for example, a game) use:

   adb shell setprop debug.gl.trace.app <package_name>

   You can find out package_name with the command adb shell pm list packages | grep "application_name".

3. Restart the application - logs will begin to be written to logcat.

USB debugging is enabled on the device|ADB drivers are installed on the PC|Adb utility is available in PATH|The package name of the target application is known-->

To disable tracing:

adb shell setprop debug.gl.trace 0

⚠️ Attention: On some devices (for example, with chipsets Qualcomm Snapdragon 8 Gen 1/2), tracing via setprop may not work due to manufacturer restrictions. In this case, try methods with root access or tools like RenderDoc.

Method 2: Editing build.prop (root required)

If you have root access, you can enable tracing permanently by editing the system file /system/build.prop. This method is useful for long-term debugging, but requires caution.

Instructions:

1. Using a file manager with root access (for example, Root Explorer), open the file /system/build.prop.
2. Add the following lines to the end of the file:

   debug.gl.trace=1
   debug.gl.trace.app=<package_name>

3. Save the file and reboot the device.

The advantage of this method is that the tracing will work immediately after the system boots, without the need to enter ADB commands. However, there are also risks:

• 🔧 Incorrect editing build.prop can lead to bootloop (loop reboot).
• 📉 Constant tracing increases the load on the CPU/GPU, which can reduce performance.

adb pull /system/build.prop /sdcard/build.prop.bak

Method 3: Android Studio Tools

For developers, the most convenient way is to use the built-in tools Android Studio. They allow you not only to enable tracing, but also to filter logs, save them to a file and visualize calls.

How it works:

1. Connect the device to Android Studio and select it in the list of devices.
2. Open Android Profiler (tab at the bottom of the window) and go to the tab OpenGL Tracer.
3. Click Start Tracing and select the target application.
4. After the tracing is completed, the logs will be displayed in the form of a tree of calls with time stamps.

Advantages of this method:

• 📊 Visualization of calls in the form of a graph (you can see the “peaks” of the load).
• 🔍 Filtering by type of commands (textures, shaders, buffers).
• 💾 Export logs to format .gltrace for further analysis.

How to read and analyze OpenGL logs

Trace logs are a stream of commands that can look intimidating to beginners. However, once you understand the structure, you can quickly find problems. A typical log consists of:

• 🕒 Time stamp (when the command was executed).
• 📛 Thread ID (important for multi-threaded applications).
• 📝 Function names (for example, glBindTexture).
• 🔢 Parameters (argument values).
• ⚠️ Error codes (if the command failed).

Example log (simplified):

[12:34:56.789] Thread-1234: glBindTexture(GL_TEXTURE_2D, 5)
[12:34:56.790] Thread-1234: glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 1024, 1024, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0x7f8a1234)
[12:34:56.795] Thread-1234: glDrawArrays(GL_TRIANGLES, 0, 36) → GL_OUT_OF_MEMORY

In this example, you can see that the application tried to load a texture of size 1024×1024, and then when calling glDrawArrays it received an error GL_OUT_OF_MEMORY (there was not enough video memory). This is a typical case when you need to either reduce the resolution of textures or optimize them. download.

Checklist for log analysis

To systematize the search for problems, follow this algorithm:

Check for errors (GL_INVALID_*, GL_OUT_OF_MEMORY)|Look for duplicate calls (for example, glBindTexture with the same ID)|Pay attention to large textures (resolution > 2048x2048)|Check the sequence of calls (for example, glUseProgram before glDraw*)|Compare logs with reference behavior (if any)-->

Some common errors and their causes:

For in-depth analysis, you can use specialized tools:

• 🛠️ RenderDoc: allows you to capture frames and analyze the state of the GPU at any time moment.
• 📊 Android GPU Inspector (AGI): a tool from Google for profiling graphics (requires Android 10+).
• 🔍 gfxinfo: a simple application for viewing logs directly on the device.

adb logcat -d > opengl_trace.log

adb logcat -d | grep "libEGL\|libGLES" > opengl_trace.log