请问如何解决注入libtest.so后无法显示出来？

[alienwu2018]

正常elf加载libtest.so是能显示出来的，正如readme提及的主意项

[Bzi-Han]

使用远程绘制，就是启动一个有权限的进程当做canvas，注入的so通过socket在canvas进程上绘制。
看这里：远程绘制
Android机器的话那两个源文件就是使用例子。
如果你想要在其他任意地方绘制的话，只要用实现一样的协议就行了，比如注入的so直接绘制到Windows的窗口上。

[alienwu2018]

好的，感谢回答，我测试一下

[alienwu2018]

验证了一下是可以的

[Bzi-Han]

嗯，如果你是模拟器的话有个很重要的问题是假设游戏本身不支持x86(跑的是转移后的arm so)，那么你注入的so也要为arm平台的so(据我观察注入x86的so无法正常与游戏内的东西互通，不同namespace？)，然后这种情况下99%可能EGL不会正常工作，导致注入的so无法初始化SrufaceView。

[alienwu2018]

上面截图是在arm层远程绘制的效果。模拟器可以注入x86的so作为跳板然后再通过native bridge加载arm so。我还是想用native绘制，但是注入的so是不走jni_onload的，无法获得java的虚拟机环境，从而也就无法获得java层的NativeWindow，如果拿到java层的NativeWindow而不是自己通过libgui创建出来的surface，我的预想是可以通过native进行绘制出的，目前这个问题让我很困扰

[Bzi-Han]

这就不清楚了，我native bridge加载arm so EGL居然不正常工作。
关于获取游戏的JNIEnv我提供一个可用的方法，就是看看游戏的哪个so是用了jni的，hook它的jni函数然后就能获得游戏的jni环境了。

[alienwu2018]

哈哈，想了2天怎么去突破suface权限问题，还是没什么头绪。还是不折腾了，老老实实hook eglswapbuffers吧。unity和ue在arm层都会调用到/nb/libEGL.so所以模拟器hook绘制不用愁，cocos2dx的处理就比较麻烦点，它是jni到x86层调用eglswapbuffers不走arm层，但是可以通过其导出的swapbuff进行hook，主流的引擎目前hook都有解决方案，不折腾native surface了QAQ

[Bzi-Han]

突破权限基本是没戏了，限制的死死的。但是可以绕弯路，比如hookSurfaceFlinger进程的权限校验的地方，检测如果是自己的窗口就直接放行。但我感觉这种方法真是脱裤子放屁。
还有一个我最近看到的思路是获取Application实例，然后通过jni调用java层SurfaceControl接口创建一个Surface，之后把这个Surface添加到Application的ViewGroup中并设置Z序。感觉挺不错的，但我没研究，远程绘制我自己用的还是挺爽的哈哈。
如果有好的库能通用hook swapbuffer的话那还不错，虽然hook始终还是可能带着那么一丢丢的风险。

[enenH]

可以用activity申请一个surfaceview获取surface哦

[Bzi-Han]

就是我下面说的那个思路，主要问题是你得能得到Application实例

[enenH]

看雪不是有很多java内存漫游吗，直接获取

[Bzi-Han]

孤陋寡闻了，加个好友？或者指个路？