Device : Samsung Galaxy Note 8 (SM-N950F)
Application : Typical GLES bootstrap app (rotating cube, implemented completely in native)
Issue : No trace appears in MGD (unrooted configuration)
Log :
I/mgd_interceptor: (2463): PassThroughEglApi: Found the following libraries for 'egl': {/system/lib64/libEGL.so}I/mgd_interceptor: (2463): PassThroughGlesApi: Found the following libraries for 'gles': {/system/lib64/libGLESv3.so, /system/lib64/libGLESv2.so, /system/lib64/libGLESv1_CM.so}D/ViewRootImpl@f0e7657[MainActivity]: Relayout returned: old=[0,0][1080,2220] new=[0,0][1080,2220] result=0x3 surface={valid=true 499709140992} changed=falseE/mgd_interceptor: (2463): SocketMessagePort: Unable to connect socket: Unable to connect socket: errno = 13W/mgd_interceptor: (2463): GatorConnection: Not connected to gatord, the application will run normally but Streamline will not collect annotations. To collect annotations, please verify you are running gatord 5.22 or later and that SELinux is disabled.D/vndksupport: Loading /vendor/lib64/hw/android.hardware.graphics.mapper@2.0-impl.so from current namespace instead of sphal namespace.E/mgd_interceptor: (2463): Interceptor: MGD failed to read the process whitelist file: No reason provided. (Does the file exist & have correct permissions?)W/mgd_interceptor: (2463): Interceptor: MGD_HEADLESS_CONFIG_FILE not specified, falling back to '/sdcard/mgd-headless.conf'E/mgd_interceptor: (2463): Interceptor: Headless config file specified was not foundE/mgd_interceptor: (2463): Interceptor: Unable to create message port - using nullI/mgd_interceptor: (2463): MarshallerBase: Connecting to daemon. Sending header...I/mgd_interceptor: (2463): Interceptor: Interceptor loaded for 2436: com.atekihcan.renI/mgd_interceptor: (2463): Interceptor: Not activating tracingI/mgd_interceptor: (2463): Interceptor: ShutdownI/mgd_interceptor: (2463): Interceptor: Host detachedI/mgd_interceptor: (2463): Interceptor: API TRACING: DisabledI/mgd_interceptor: (2463): Interceptor: ASSET TRACKING: EnabledI/mgd_interceptor: (2463): Interceptor: API TRACING: DisabledI/mgd_interceptor: (2463): Interceptor: ASSET TRACKING: Disabled
Troubleshooting guide as well as some threads in this forum suggests the solution is to change SELinux to permissive mode (adb shell setenforce 0). However, if I understand correctly, I cannot do that if the device is not rooted.
Is there anyway I can make tracing work in un-rooted configuration?
The error you are getting (errno = 13) is a permissions denied error, which sounds like the device security policy is blocking the interceptor from creating a Unix domain socket. This is generally not something that is possible to fix on a non-root device, but we definitely have non-root devices where this is possible.
It might be worth checking application permissions related to network access; requesting "android.permission.INTERNET" in the application manifest might potentially help for example. I don't have access to an unrooted Note 8 to check myself unfortunately.
HTH, Pete
P.S. Can you confirm which Android version and firmware version you have on the device?
Thank you for your reply.
However, Internet permissions "android.permission.INTERNET" and "android.permission.ACCESS_NETWORK_STATE" are already in the manifest.
Android 9 Pie, firmware version PPR1.180610.011.N950FXXU5DSB2
Thanks for checking. We'll try and investigate more with the engineering team here and let you know if we have any more ideas.
Next check - what API version are you compiling your application with? We've spotted some issues due to security policy changes where applications compiled with targetSdkLevel >= 26 fail to create sockets. Compiling the application with targetSdkLevel 25 or lower seems to work on the devices where we've hit problems.
Spot on!
I had targetSdkVersion set to latest SDK version 28. I'm able to capture trace as soon as I changed that to 25.
Thank you so much for helping me with this.
Just out of curiosity, do you guys have anything planned solve the security issue for latest SDK versions?
Thanks for checking, and confirming this was the issue.
We don't have a specific fix identified yet - the issue and the workaround we proposed is hot off the press - but this is something we definitely need to fix as we can't expect application developers to use old SDK versions.
Regards, Pete