[Feature] Run on Android. about castanets HOT 4 OPEN

Just a quick question regarding castanets support for Android.
I thought we can use chromium's posix code for shared memory on Android platform instead of ashmem so that we can have easy communication between linux/tizen-android.
On my verification of this approach, simple web pages work in linux(browser)-android(renderer) case.

So thought of asking your ideas on this.
@hyowon @hyunaranda @is46-kim @yg48 @joonghunpark @Chikdolman @Sunwoo-Nam

Will it be ok to use posix shared memory on Android. Or do we need to stick to ashmem ?

from castanets.

I think using shared_memory_posix on Android is okay.

from castanets.

The current status with the #146
basic google page rendering is working fine with Linux(B)-Android(R) case.

Visibly the performance seem to be slower than castanets_63 (linux-android case).

As we are using posix code for android now, the shared memory file path used is application's cache directory path which is /data/user/0/org.chromium.chrome/cache which is a regular file system. This seems to be the reason for the slow performance.
[base/files/file_util_android.cc].

Android's ashmem created file in /dev/ashmem which is a tmpfs. (RAM memory)
Even in Linux, tizen we use /dev/shm which is also tmpfs.

Opening /dev/ path through the posix code in android is not possible due to platform security.

from castanets.

Gpu Compositing on Android: #155

1. GpuMemoryBufferHandle's mojo struct difference causes VALIDATION_ERROR_HEADER_UNKNOWN_METHOD. AHardwareBufferHandle is not required for the gpu compostion path. So it is made not to use it for now for castanets.
2. Data types of SurfaceHandle are different between linux and android (int32_t vs AcceleratedWidget/unsigned long). So the data types are unified.
3. As GpuBlackList entries are also part of mojo msgs, if the entries are different we face a DESERIALIZATION ERROR. So IgnoreGpuBlackList flag is added for linux, android for now.

from castanets.