Removing unmanaged APIs

[bwikbs]

Problem

Unmanaged APIs should not be used for app store registration.
(This issue is also related to flutter-tizen/flutter-tizen#10. because wayland related functions are also unmanaged APIs)

refer to :

• Publish: Undocumented APIs is detected (allow list) flutter-tizen#21 (Unmanaged API issue bwikbs/engine#1)
• https://developer.samsung.com/galaxy-store/self-check-list-galaxy-watch.html

gear_core_allowlist.txt (List of APIs rejected by store)

• eglBindAPI[libflutter.so]
• eglCreateContext[libflutter.so]
• eglDestroyContext[libflutter.so]
• eglCreateWindowSurface[libflutter.so]
• eglDestroySurface[libflutter.so]
• eglTerminate[libflutter.so]
• eglMakeCurrent[libflutter.so]
• eglSwapBuffers[libflutter.so]
• eglCreatePbufferSurface[libflutter.so]
• eglGetCurrentDisplay[libflutter.so]
• eglQueryString[libflutter.so]
• eglChooseConfig[libflutter.so]
• eglGetError[libflutter.so]
• eglInitialize[libflutter.so]
• eglGetProcAddress[libflutter.so]
• eglGetDisplay[libflutter.so]
• ecore_wl2_window_geometry_get[libflutter.so]
• ecore_wl2_window_show[libflutter.so]
• ecore_wl2_egl_window_resize_with_rotation[libflutter.so]
• ecore_wl2_sync[libflutter.so]
• ecore_wl2_window_free[libflutter.so]
• ecore_wl2_display_connect[libflutter.so]
• ecore_wl2_egl_window_native_get[libflutter.so]
• ecore_wl2_egl_window_create[libflutter.so]
• ecore_wl2_window_new[libflutter.so]
• ecore_wl2_window_type_set[libflutter.so]
• ecore_wl2_display_disconnect[libflutter.so]
• ecore_wl2_egl_window_destroy[libflutter.so]
• ecore_wl2_init[libflutter.so]
• ecore_wl2_display_get[libflutter.so]
• ecore_wl2_window_alpha_set[libflutter.so]
• ecore_wl2_window_id_get[libflutter.so]
• ecore_wl2_shutdown[libflutter.so]
• ecore_wl2_window_aux_hint_add[libflutter.so]
• ecore_device_name_get[libflutter.so]
• ecore_device_class_get[libflutter.so]
• ecore_device_subclass_get[libflutter.so]
• tdm_client_vblank_destroy[libflutter.so]
• tdm_client_handle_events[libflutter.so]
• tdm_client_get_output[libflutter.so]
• tdm_client_create[libflutter.so]
• tdm_client_destroy[libflutter.so]
• tdm_client_vblank_set_enable_fake[libflutter.so]
• tdm_client_output_create_vblank[libflutter.so]
• tdm_client_vblank_wait[libflutter.so]
• tbm_surface_internal_is_valid[libflutter.so]
• tbm_surface_internal_unref[libflutter.so]
• tbm_surface_internal_ref[libflutter.so]
• _ZTHN4dart8OSThread18current_vm_thread_E[libflutter.so]
• __dlog_print[libflutter.so]

[bwikbs]

AFAIK, Here are some things we can do for this:

1. Use EvasGL
2. Use SDL
3. Use bypass methods like dlopen (I'm not sure if it fits all cases..but I know of some cases that worked)

[bwikbs]

For the last few days, I have been working on a POC using EvasGL, and I succeeded in partially drawing the like following.(only TM1, TW3 still has skia initialization problems. )

However, the screen update didn't work properly, and I found out that this is a problem with evas_object_image_pixels_get_callback_set API.
The action drawing in EvasGL should only happen in a specific callback in the main thread, and this doesn't fit our situation.
To do this, we will have to draw the texture in our rendering thread and draw it back in the main thread.
This will take unnecessary complex steps and consume a lot of extra resources than now and raise the question of why we should use EvasGL.

[bwikbs]

I am wondering if the dlopen method is our right direction for this issue. That's not a nice way, but it seems that we can solve this problem by a reasonable cost.

[xuelian-bai]

First, I think the best way to solve this issue is to filter these APIs for flutter.so, Flutter should use low level APIs instead of wrapped APIs.
Second, dlopen only work for shared library, and it takes time to load shared library, performance may be affected.

[bbrto21]

To do this, we will have to draw the texture in our rendering thread and draw it back in the main thread.

Flutter allows you to use the main thread as the render thread. If there is no big problem with rendering performance, maybe this is a good solution.

[bwikbs]

Flutter allows you to use the main thread as the render thread. If there is no big problem with rendering performance, maybe this is a good solution.

Plz, Let me know how

[bwikbs]

First, I think the best way to solve this issue is to filter these APIs for flutter.so, Flutter should use low level APIs instead of wrapped APIs.

Please explain in more detail. I don't know what you intend to do yet...

Second, dlopen only work for shared library, and it takes time to load shared library, performance may be affected.

Hm.. I'm not sure what you mean. Is there anything we use other than shared? Didn't we have to use it anyway?

[bbrto21]

Please refer to the two below
https://github.com/flutter/flutter/wiki/The-Engine-architecture#threading

typedef struct {
  /// The size of this struct. Must be sizeof(FlutterCustomTaskRunners).
  size_t struct_size;
  /// Specify the task runner for the thread on which the `FlutterEngineRun`
  /// call is made. The same task runner description can be specified for both
  /// the render and platform task runners. This makes the Flutter engine use
  /// the same thread for both task runners.
  const FlutterTaskRunnerDescription* platform_task_runner;
  /// Specify the task runner for the thread on which the render tasks will be
  /// run. The same task runner description can be specified for both the render
  /// and platform task runners. This makes the Flutter engine use the same
  /// thread for both task runners.
  const FlutterTaskRunnerDescription* render_task_runner;
} FlutterCustomTaskRunners;

[bwikbs]

The action drawing in EvasGL should only happen in a specific callback in the main thread,

@bbrto21 Your suggestion solved the main thread part, but not the specific callback part.
Anyway, I'll try it and share the result. (Maybe it will work properly...)

[xuelian-bai]

First, I think the best way to solve this issue is to filter these APIs for flutter.so, Flutter should use low level APIs instead of wrapped APIs.

Please explain in more detail. I don't know what you intend to do yet...

I mean it's no problem to use these APIs theoretically, because it's more suitable for Flutter to use low level APIs, or why not everyone use SDL? By using lower level APIs can give flutter engine more flexibility.
So, I think Galaxy Store should modify its policy to allow flutter.so to use those APIs.

Second, dlopen only work for shared library, and it takes time to load shared library, performance may be affected.

Hm.. I'm not sure what you mean. Is there anything we use other than shared? Didn't we have to use it anyway?

I mean you can only get function name from shared library by dlsym. I'm not sure if following APIs could be got by dlsym
_ZTHN4dart8OSThread18current_vm_thread_E[libflutter.so]
__dlog_print[libflutter.so]
Even you get there function pointer, you will still have to include their header files, is that allowed by Galaxy Store?

[bwikbs]

I mean it's no problem to use these APIs theoretically, because it's more suitable for Flutter to use low level APIs, or why not everyone use SDL? By using lower level APIs can give flutter engine more flexibility.
So, I think Galaxy Store should modify its policy to allow flutter.so to use those APIs.

Ah... I understand what you mean. I totally agree with you... but I'm not sure.. (maybe it's possible... 😄 who knows..)

I mean you can only get function name from shared library by dlsym. I'm not sure if following APIs could be got by dlsym
_ZTHN4dart8OSThread18current_vm_thread_E[libflutter.so]
__dlog_print[libflutter.so]
Even you get there function pointer, you will still have to include their header files, is that allowed by Galaxy Store?

I tried to see why these things come out... I don't understand well...

[bwikbs]

After applying the boram's suggestion, it seems to work. I don't feel any deterioration in performance.
I think EvasGL could be one of our options again.

[bwikbs]

I tried to see why these things come out... I don't understand well...

This is the result of investigation regarding above issue.
First of all I can find following symbol in our so.

 26: 00000000     0 FUNC    GLOBAL DEFAULT  UND __dlog_print
 80: 00000000     0 NOTYPE  WEAK   DEFAULT  UND _ZTHN4dart8OSThread18curr

And I also find this symbol dart::OSThread::current_vm_thread_ in our source code. (Yes. This is symbol we have... ❗)

third_party/dart/runtime/vm/os_thread.cc:24:thread_local ThreadState* OSThread::current_vm_thread_ = NULL;

It seems that the store search undefined dynamic symbols which is not belong to white list In my guess.
So I think you can make those symbols undetected by tweaking the compilation. (Of course, a little trial and error is required.)

[xuelian-bai]

__dlog_print can be solved, since dlog is allowed, we may called the wrong function
https://docs.tizen.org/application/native/api/wearable/4.0/group__CAPI__SYSTEM__DLOG.html

[bwikbs]

Cool. Now we only figure out how dart::OSThread::current_vm_thread_ is binded our so file.

[bwikbs]

symbol TLS init function for dart::OSThread::current_vm_thread_ is associated with following code
third_party/dart/runtime/vm/os_thread.h

// On iOS, thread_local requires iOS 9+.
#if !HOST_OS_IOS
#define HAS_C11_THREAD_LOCAL 1
#endif
...
#if defined(HAS_C11_THREAD_LOCAL)
  static thread_local ThreadState* current_vm_thread_;
#endif

And I'm not sure how to elegantly solve it without touching third_party/dart.

[xuelian-bai]

symbol TLS init function for dart::OSThread::current_vm_thread_ is associated with following code
third_party/dart/runtime/vm/os_thread.h

// On iOS, thread_local requires iOS 9+.
#if !HOST_OS_IOS
#define HAS_C11_THREAD_LOCAL 1
#endif
...
#if defined(HAS_C11_THREAD_LOCAL)
  static thread_local ThreadState* current_vm_thread_;
#endif

And I'm not sure how to elegantly solve it without touching third_party/dart.

Actually I don't understand why this warning happen? because thread_local is undefined?

[bwikbs]

Well, in my opinion, the store simply detects external symbols that are not on the whitelist. and gcc generate a special symbol for the TLS variable, which seems to be detected by store.
So.. we should not use TLS for avoiding this situation.
Fortunately, not using TLS does not cause any problems with the current engine, so I want to turn it off if possible.

[bwikbs]

I heard that the store will change policies for us.
So I think we don't need to proceed with this work anymore at this moment
I will open it again later if necessary.