Hi,
I'm trying to profile a game with MGD 2.0.1 without success. So far my status is that I successfully managed to connect to target in the MGD GUI but no trace data is displayed.
Logcat is not displaying any information on the intercepted lib. I don't know what I am missing.
ligGLES_mgd.so and mgddaemon are inside /system/lib/egl and there's a symbolic link libGLES_mgd.so pointing to libGLES.so
I tried both with processlist.cfg and without it. egl.cfg contains "0 0 mali" (as per instructions on android 4.4 telling no need to do "0 0 mgd"
Host: Windows 7
Target: Note 4 910H Android 4.4.4 running an APK generated by Unity 4.6
Kind Regards,
Phil Lira.
Hi Phil,
If logcat is not displaying any output from the interceptor lib then this is because the Android EGL loader is not picking it up. The EGL loader mechanism on Android 4.4, from memory, basically looks for something called libGLES.so, and if it doesn't find it, looks for anything matching the now deprecated tag naming scheme, libGLES_<tag>.so, and takes the first thing it sees. The user guide seems to expect that the driver won't have gone for the primary method of just calling the library libGLES.so, so the intention is that you create a symlink called libGLES.so that points to libGLES_mgd.so, and EGL picks it up first. I'd sanity check that there isn't a libGLES.so in /vendor/lib/egl etc which might be getting picked up first, and also, have you restarted the OS before attempting to trace an app? The system must be restarted in order for the new lib to be picked up (older versions of Android it was sufficient to just restart the app process by force closing it).
If you still have trouble can you provide directory listings of /vendor/lib/egl/ and /system/lib/egl/ as they were before you started?
Cheers,
Chris
Thanks Chris.
I restarted the OS. Here's my directory listing of both /system/lib/egl and /vendor/lib/egl
The symbolic link from libGLES_mgd to libGLES is there as you can see. I tried using egl.cfg with both "0 0 mgd" and "0 0 mali". Restarting OS between changes.
There are two apps in gpr_list.cfg, none of them are mine.
Still no info on the intercep lib showing up on logcat and on mgd client.
The only thing I noticed on logcat, and might be unrelated to this, is the following line:
W/ContextImpl( 3367): Calling a method in the system process without a qualified user: android.app.ContextImpl.sendBroadcast:1510 com.absolute.android.persistservice.a.run:1059 java.lang.Thread.run:841
I really do know what to do next...
Phil Lira
Hi philira,
Could you also output ls -al for the mgdaemon and its location?
When you run the daemon, can you also show us the information it outputs?
Thanks
Michael McGeagh
My gut feel on this is that your build of Android ignores /system/lib/egl entirely and is just picking up the libGLES_mali.so from /vendor/lib/egl. We write the interceptor against the Android reference source, but it wouldn't be the first time I've seen vendors change that behaviour. What happens if you put libGLES_mgd.so in /vendor/lib/egl and call it libGLES.so?
I get the following:
Chris,
It bricked my device :/
Can you double check if the intercept lib is working with Android 4.4.4?
Hi Philra,
ADB is supposed to come up before surfaceflinger etc so you should still have ADB access to revert the changes. It bricked when you put the interceptor at /vendor/lib/egl/libGLES.so? That's good information, does it do the same when you put it at /system/lib/egl, naming it libGLES.so rather than creating a symlink? If not then that definitely points to non-vanilla EGL code in that Android build. To the best of my knowledge we support vanilla 4.4.4 but I will double check that with the team.
Chris Varnsverry escreveu: It bricked when you put the interceptor at /vendor/lib/egl/libGLES.so?
Chris Varnsverry escreveu:
It bricked when you put the interceptor at /vendor/lib/egl/libGLES.so?
Positive. I'm not sure how to revert through ADB since the OS is loooping and Volume Up, Power + Home doesn't work. :O.
I'm not sure if this device is vanilla or not. I'll probably need a binary/bootloader to flash from scratch and I might get it or not depending on the mobile test team providing me one.
Hi Philira,
I can confirm that we've had MGD working with Android 4.4.4, on a Note 4 N910. I'm confirming exactly which variant. They reported that it worked fine from /system/lib/egl so I'm a bit stumped on this one. If you put libGLES_mgd.so in /system/lib/egl/ and rename it to libGLES.so does it work? Worst case if ADB isn't working then you can grab a binary from http://www.sammobile.com/firmwares/database/SM-N910H/ and use Odin to flash it.
Ok. I applied a firmware I got from my team got the phone back working.
I tried copying libGLES_mgd.so to system/lib/egl with the name of libGLES.so. Bricked the device again.
So it seems the system can't use _mgd variant. Any ideas why?
I am sorry to hear you are having such annoying technical issues. We are investigating what may have happened in your case, we are using MGD successfully on Note 4 here.
We will let you know as soon as we have more information.
In the meantime, would you be able to send us a logcat of the device before it gets stuck? That's useful information.
Thanks,
Lorenzo
You mention you got a firmware from your team... Can you test it on a stock firmware available from SamMobile? Is there anything special / non-standard about the firmware your team are giving you? This seems to be a variable worth ruling out. Also one of our guys noticed in your original screenshot the link was pointing to ligGLES_mgd.so, notice the g, so that explains why it didn't brick in that case.
Thanks Chris. I really appreciatte the effort you guys are putting into this.
Really nice you catch that link typo. I'll pay more attention from now on.
I'm downloading one of the firmwares from SamMobile (N910C NK5). I know I previously said to you it was a N910H. That was a mistake, the 910H I have is not the device I'm testing this on. MGD is supposed to also work on 910C right?
Due to my NDA I cannot disclose any detailed information of the firmware version I flashed last (which is different from the first one I had).
I'll let you know as soon as I flash the SamMobile one and them I'll provide all the detailed info on it. I should get back to you tomorrow at most.
Phil
Hi Lorenzo,
I'm flashing a stock firmware from SamMobile as Chris advised and hopefully we'll be able to track this more easily with the same exact firmware.
Lorenzo Dal Col escreveu: In the meantime, would you be able to send us a logcat of the device before it gets stuck? That's useful information.
Lorenzo Dal Col escreveu:
Do you mean when the device got stucked in OS loop? I'm not sure how to attach ADB in that case. When the device is bricked I can only get to the ODIN Download screen.
Let me know whatever you want to try to figure out this and I'll do.
It would be really great if I could get MGD working by the end of this week.
No worries, understand NDAness AFAIK there is the H C and S which are all Exynos (someone feel free to correct me) but in any case you seem to have an Exynos one so the SoC shouldn't be an issue. The ROM at this point is much more likely to be problematic, so if we can confirm that you could raise it with the source of your rom... It's possible they have made some mods to the driver stack which MGD is not compatible with, i.e. the OS is looking for some hooks that are not there etc.
Hth,
I believe S is Snapdragon. I don't have any with me now. So far, only Exynos/Mali T Love