Hello Mali devs,
Are there any plans to provide MGD for non rooted devices?
Looking at the setup instructions for rooted, it seems like it could be achieved with a combination of linkage to interceptor libs + override SO preloading in tandem with running the daemon as a run-as target. I haven't experimented directly yet but it seems it could be done.
Thanks!
Stephane
This sounds like a reasonable requirement, I'm not 100% on whether this will work right now but it's worth trying. Can you run mgddaemon from /sdcard/, or in some other way that doesn't require root?
I suppose you could take the libGLES_mgd.so and bundle this with your application, tell your Android.mk file to pull it in as a prebuilt shared library and link against it instead of libGLESv2,so. The library will still look in /system/lib/egl etc for the real thing so it might just work... Let me know if you give it a try and I'll do some testing at my end also.
Thanks for the suggestion,
Chris
On my nexus 10 I can't get mgddaemon to run from /sdcard, as need chmod to give it execute permissions which needs root I suppose it's possible to install the daemon properly as an APK, but obviously this is not implemented at present.
Thanks,
Hi Chris,
I believe I've worked out a method that appears to work nicely. Let me know if you see any issues with it.
1) Add libGLES_mgd.so as a prebuilt sharedlibrary to Android.mk
2) Replace GLESv1_CM or GLESv2 with GLES_mgd in the library link list in Android.mk and add $(MGD_ROOT)/target/arm_android to the library search paths.
3) Rename mgddaemon to libmgddaemon.so
4) Add libmgddaemon.so as a prebuilt sharedlibrary to Android.mk (this just tricks the APK packager to install the executable with +x permissions).
* Steps 3&4, one can also rename mgddaem to gdbserver or use AAPT to insert the executable to lib/$ARCH_ABI/)
5) In main activity's onCreate(), add System.loadLibrary("libGLES_mgd")
6) Build and install APK.
7) adb forward tcp:5002 tcp:5002
8) adb shell run-as $PACKAGENAME lib/libmgddaemon.so (won't work on certain Android 4.3 due to the run-as bug that was later addressed in KitKat Issue 58373 - android - run-as doesn't work after update to 4.3 - Android Open Source Project - Issue Tracker - Googl… in which case the launch can we wrapped in a service).
9) Launch the application on unrooted target
10) Launch MGD and connect to 127.0.0.1:5002
And voila, MGD on unrooted devices:
Daemon is version: A006
Waiting for an interceptor to connect...
Waiting for a connection from the host on port 5002...
A client is connected.
Interceptor is version: A006
Host connected.
Host disconnected.
Host connection closed.
Also, with this method, egl.cfg modifications shouldn't required since the GLES interceptor lib is only linked to a single application.
Best,
Nice =)
Just to check I'm reading this right the "Android.mk" you are hacking about is the one for the application you want to profile right?
*EDIT1* The only thought I have is whether this works in all cases. In Android you normally link against Google's GLES and EGL libraries, and they in turn dlopen the real library based on the egl.cfg. The Google libraries do some preflight work before calling into the real libraries for some pieces of functionality (I'll be honest and say I don't know _exactly_ what they do). I suspect with this approach you bypass the Google libraries, and hence their intercept code path completely; I'm not entirely sure what the implications of this are ...
*EDIT2* Actually it "could just work" if libGLES_mgd could be convinced to dlopen the Google shim libraries instead of libGLES_mali.so.
Cheers, Pete
Hi Peter,
Indeed, by Android.mk, I am referring to the application's makefile.
So far it does seem to work in all cases (only tested on GLES 2.0 (Mali 400-MP), and not on 3.0 T6xx, yet). However, if that weren't the case, given this method, a separate GLES_mgd_noroot.so could be quite easily created to fulfil link/runtime requirements on this side (seems to be the case currently) .
On a side note, minor misreporting issue with MGD. It reports "unsupported texture internal format" for supported extensions BGRA, depth texture and depth/stencir texture.
Hi Stephane,
Thanks for your pointers and for testing this, good to hear it works. I shared some of Pete's concerns about bypassing the Android layer, so surprised it's working!
Thanks also for pointing out the run-as method, shame about the 4.3 bug but what can you do.
As for the misreporting issue, I think MGD is saying that IT does not support that particular format, so cannot display it in MGD, not that the driver does not. I'll feed this back so we can improve the message, and hopefully prioritize the implementation of those paths.
Thanks again,
EDIT: Internal ticket for the texture support and ambiguous error is MGD-1050 in case you need to quote in future.