Bzi-Han
Bzi-Han
使用远程绘制，就是启动一个有权限的进程当做canvas，注入的so通过socket在canvas进程上绘制。 看这里：[远程绘制](https://github.com/Bzi-Han/AndroidSurfaceImgui#rpc%E4%BD%BF%E7%94%A8) Android机器的话那两个源文件就是使用例子。 如果你想要在其他任意地方绘制的话，只要用实现一样的协议就行了，比如注入的so直接绘制到Windows的窗口上。
嗯，如果你是模拟器的话有个很重要的问题是假设游戏本身不支持x86(跑的是转移后的arm so)，那么你注入的so也要为arm平台的so(据我观察注入x86的so无法正常与游戏内的东西互通，不同namespace？)，然后这种情况下99%可能EGL不会正常工作，导致注入的so无法初始化SrufaceView。
这就不清楚了，我native bridge加载arm so EGL居然不正常工作。 关于获取游戏的JNIEnv我提供一个可用的方法，就是看看游戏的哪个so是用了jni的，hook它的jni函数然后就能获得游戏的jni环境了。
突破权限基本是没戏了，限制的死死的。但是可以绕弯路，比如hook[SurfaceFlinger进程的权限校验的地方](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp;l=4769)，检测如果是自己的窗口就直接放行。但我感觉这种方法真是脱裤子放屁。 还有一个我最近看到的思路是获取Application实例，然后通过jni调用java层SurfaceControl接口创建一个Surface，之后把这个Surface添加到Application的ViewGroup中并设置Z序。感觉挺不错的，但我没研究，远程绘制我自己用的还是挺爽的哈哈。 如果有好的库能通用hook swapbuffer的话那还不错，虽然hook始终还是可能带着那么一丢丢的风险。
就是我下面说的那个思路，主要问题是你得能得到Application实例
孤陋寡闻了，加个好友？或者指个路？
此库默认就是使用EGL实现的
如果你是app环境的话一般是命名空间限制无法加载系统库，解决方案是自己解析已加载的so，比如使用`dl_iterate_phdr`或者解析`/proc/self/maps`。 然后在调用任何 ANativeWindowCreator 函数之前先调用 `ANativeWindowCreator::SetupCustomApiResolver` 设置并调用自定义符号解析依赖函数即可。
改成这样试试 ```cpp ImGuiIO& io = ImGui::GetIO(); ImFont *font = io.Fonts->AddFontFromMemoryTTF( (void*) _binary_font_ttf_start, _binary_font_ttf_end - _binary_font_ttf_start, 24.0f, nullptr, io.Fonts->GetGlyphRangesChineseSimplifiedCommon() ); IM_ASSERT(font != nullptr); io.FontDefault = font; io.Fonts->Build(); LogDebug("Font: %p", font); LogDebug("Font...
Ref this #28