Unexpected output of 'dumpsys SurfaceFlinger' command: no GL extensions found. #12919

Activity

1. gmck

   added

   Area: App+Library BuildIssues when building Library projects or Application projects.Issues when building Library projects or Application projects.

   needs-triageIssues that need to be assigned.Issues that need to be assigned.

   on Sep 24, 2026
2. jonathanpeppers commented on Sep 25, 2026

   

   jonathanpeppers

   on Sep 25, 2026

   Member

   More actions

   🤖 This message comes from Google's bundletool while it detects the connected device's capabilities, not from the app or Visual Studio. Bundletool runs adb shell dumpsys SurfaceFlinger and looks for a SurfaceFlinger global state: header, a GLES: line, and a following GL-extensions line. If it cannot find that sequence, it prints this warning and proceeds with an empty GL-extension list. Your logs show that the APK build and deployment still succeed; unlike the older failure in #8368, this is non-fatal.

   Could you share the Pixel 9's Android version and the relevant lines from adb -s 49280DLAQ005DD shell dumpsys SurfaceFlinger (around SurfaceFlinger global state:, GLES:, and the following line, if present)? That will show whether the device omits that information or reports it in a format bundletool does not recognize. Bundletool parser
3. jonathanpeppers

   added

   need-infoIssues that need more information from the author.Issues that need more information from the author.

   and removed

   needs-triageIssues that need to be assigned.Issues that need to be assigned.

   on Sep 25, 2026
4. dotnet-policy-service commented on Sep 25, 2026

   

   dotnet-policy-servicebot

   on Sep 25, 2026 – with Dotnet Policy Service

   More actions

   Hi @gmck. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.
5. jonathanpeppers commented on Sep 25, 2026

   

   jonathanpeppers

   on Sep 25, 2026

   Member

   More actions

   I think the AI is on the right track, but Google does have bundletool on GitHub so you could report it there.
6. gmck commented on Sep 26, 2026

   

   gmck

   on Sep 26, 2026

   Author

   More actions

   @jonathanpeppers

   I’m a bit out of my depth on SurfaceFlinger, so this is a GitHub Copilot summary after looking at the raw output.
   I think I misunderstood the earlier request. I had provided the bundletool / deployment log showing:
   · build-apks --connected-device
   · install-apks
   · Unexpected output of 'dumpsys SurfaceFlinger' command: no GL extensions found.
   But it now seems you may have been asking for the raw output from:
   adb shell dumpsys SurfaceFlinger
   I captured that from the affected Pixel 9 and reviewed it. The main thing Copilot noticed is that the dump does not appear to contain the older-style GL/EGL lines that bundletool seems to be looking for, such as:
   · GL_EXTENSIONS
   · EGL_EXTENSIONS
   · GL_VENDOR
   · GL_RENDERER
   · GL_VERSION
   Instead, the output looks more Vulkan-oriented. For example, it includes entries like:
   · SurfaceFlinger global state:
   · RE Vulkan (Graphite)
   · Vulkan device initialized: 1
   · Name: Mali-G715
   · Supported API version: 1.4.343
   · Enabled instance extensions: []
   · Enabled device extensions: [ VK_* ... ]
   It also contains:
   · Sync configuration: [using: EGL_ANDROID_native_fence_sync EGL_KHR_wait_sync]
   So Copilot’s guess is that bundletool may still be expecting GL extension output in an older format, while this device/OS is returning Vulkan-oriented renderer information instead. That seems consistent with the warning:
   Unexpected output of 'dumpsys SurfaceFlinger' command: no GL extensions found.
   For context, deployment still succeeds and the app runs normally. I also see the same behavior with both:
   · net10.0-android36.1
   · net11.0-android37.0
   and in both VS Community and VS Insiders.

   I've attached the full raw adb shell dumpsys SurfaceFlinger.

   I've now noticed that it doesn't produce the warning every time that I build and deploy, but I can't establish a pattern for that behaviour.

   SurfaceFlinger.txt

   .
7. dotnet-policy-service

   added

   need-attentionA xamarin-android contributor needs to reviewA xamarin-android contributor needs to review

   and removed

   need-infoIssues that need more information from the author.Issues that need more information from the author.

   on Sep 26, 2026
8. jonathanpeppers commented on Sep 28, 2026

   

   jonathanpeppers

   on Sep 28, 2026

   Member

   More actions

   If you can capture the log from bundletool, you could file an issue with Google upstream at:

   • https://github.com/google/bundletool
9. jonathanpeppers

   added

   need-infoIssues that need more information from the author.Issues that need more information from the author.

   and removed

   need-attentionA xamarin-android contributor needs to reviewA xamarin-android contributor needs to review

   on Sep 28, 2026
10. dotnet-policy-service commented on Sep 28, 2026

    

    dotnet-policy-servicebot

    on Sep 28, 2026 – with Dotnet Policy Service

    More actions

    Hi @gmck. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.
11. gmck commented on Oct 2, 2026

    

    gmck

    on Oct 2, 2026

    Author

    More actions

    Hi @jonathanpeppers ,

    Both VS and Insiders were upgraded yesterday morning. At the time, I was working with Community on my production app. I deployed the app many times yesterday on different devices without getting the SurfaceFlinger error. This morning I published it to production. After that, I loaded the same project in Insiders, and the SurfaceFlinger error message returned immediately. So I don't see any reason to notify https://github.com/google/bundletool, since it now appears to be an anomaly only in Insiders.
12. dotnet-policy-service

    added

    need-attentionA xamarin-android contributor needs to reviewA xamarin-android contributor needs to review

    and removed

    need-infoIssues that need more information from the author.Issues that need more information from the author.

    on Oct 2, 2026
13. jonathanpeppers commented on Oct 2, 2026

    

    jonathanpeppers

    on Oct 2, 2026

    Member

    More actions

    What are the two versions of bundletool.jar? Community vs Insiders.

    Or the two versions of the Android workload?
14. jonathanpeppers

    added

    need-infoIssues that need more information from the author.Issues that need more information from the author.

    and removed

    need-attentionA xamarin-android contributor needs to reviewA xamarin-android contributor needs to review

    on Oct 2, 2026
15. dotnet-policy-service commented on Oct 2, 2026

    

    dotnet-policy-servicebot

    on Oct 2, 2026 – with Dotnet Policy Service

    More actions

    Hi @gmck. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.
16. gmck commented on Oct 3, 2026

    

    gmck

    on Oct 3, 2026

    Author

    More actions

    Hi @jonathanpeppers ,

    It's getting even weirder. It now seems to depend on what I deploy to. Both of these Pixels are Android 17 and have been upgraded to the latest versions - CP3A.260905-009. I thought the problem was gone with 2026 Community, but it clearly isn't. For these tests, all I did was Clean the Solution and Clean obdnowpros, then deploy in each case. I don't deploy to the Pixel 10 that often because that is my work phone. I really only use the Pixel10 when I want to test in my vehicles. To get a normal build, I usually deploy to either Pixel6 through to Pixel 9 and then connect to my OBD Simulator to check whatever the latest test was.

    Would it be more useful if I sent you two bin logs? Therefore, at this stage, I don't see much point in sending the same RC2 info. Do you have an estimated time for RC3, and perhaps wait for it?

    Pixel 10.

    Visual Studio 2026 Community.
    Building with .NET SDK Version: 10.0.401

    C:\Program Files\Android\openjdk\jdk-21.0.8\bin\java.exe -Xmx1G -jar "C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\36.1.69\tools\bundletool.jar" install-apks --apks obj\Release\net10.0-android36.1\android\bin\com.glmsoftware.obdnowpros.apks --adb "C:\Program Files (x86)\Android\android-sdk\platform-tools\adb.exe" --device-id 49280DLAQ005DD --allow-downgrade --modules ALL

    Pixel 9.
    Visual Studio 2026 Community
    Building with .NET SDK Version: 10.0.401

    C:\Program Files\Android\openjdk\jdk-21.0.8\bin\java.exe -Xmx1G -jar "C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\36.1.69\tools\bundletool.jar" build-apks --connected-device --mode default --adb "C:\Program Files (x86)\Android\android-sdk\platform-tools\adb.exe" --device-id 49280DLAQ005DD --bundle obj\Release\net10.0-android36.1\android\bin\com.glmsoftware.obdnowpros.aab --output obj\Release\net10.0-android36.1\android\bin\com.glmsoftware.obdnowpros.apks --aapt2 "C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\36.1.69\tools\aapt2.exe" --ks C:\glmkeystore\upload_key.keystore --ks-key-alias upload_key --key-pass file:c:\glmkeystore\KeyPassword.txt --ks-pass file:c:\glmkeystore\KeyStorePassword.txt
    Unexpected output of 'dumpsys SurfaceFlinger' command: no GL extensions found.
17. dotnet-policy-service

    added

    need-attentionA xamarin-android contributor needs to reviewA xamarin-android contributor needs to review

    and removed

    need-infoIssues that need more information from the author.Issues that need more information from the author.

    on Oct 3, 2026