On Thu, 7 Feb 2013 23:18:59 +0100 Andreas Volz <[email protected]> wrote:
> Am Sat, 2 Feb 2013 23:56:02 +0100 schrieb Andreas Volz: > > > Hello together, > > > > I'm currently trying to port some EFL libs to android. > > Just like to report some success about this task. > > The EFL is working successful on android platform. Up to now I ported > the buffer engine and use a native android bitmap to display rendered > result. :-) > > As next task I like to polish it more and commit changes to SVN. I'll > raw summarize my needed changes so anyone could add a comment before I > start with this task. Please give me some comments. > > I won't provide any patches at the moment, because I used efl-1.7.5 > and need to port it to trunk and I like to discuss them before. > > Library versions > ---------------- > Android doesn't well support the library versions (libxyz.so.1). Each > application or library package is independent from others. So no need > to use versions.I had to modify all Makefile.am to replace: > > "-version-info @version_info@ @release_info@" => "-avoid-version". > > Module structure > ---------------- > The app resources on android support only flat directory structure. So > I had to change module structure > > /lib/evas/modules/engines/software_x11/linux-gnu-x86_64-1.7.99/module.so > > isn't possible. This goes together with next change... > > Module name > ----------- > For some reasons shared objects on android need to be named lib*.so to > be correct included. Maybe this is also a limitation of the package > creator. Don't know for sure. But for this reasons I decided to name > modules like this: > > libevas_modules_engines_buffer.so > libevas_modules_engines_software_generic.so > > (PS: if you are more experienced with android and teach me a better > way to solve the library restrictions, please do so!) > > Module loader (evas) > -------------------- > I had to modify module loader evas-1.7.5/src/lib/file/evas_module.c to > load modules from the new place in evas_module_paths_init(). In my > case here local hacked to "/data/data/com.example.efl/lib/". The > correct way would be for sure to get this path dynamic. Seems that > this path is only available in the Java API. So I've to get it by JNI > calls from Java. Other people out there do the same trick to solve > this. > > I've to port evas_module_engine_list() for sure too. But until now I > could survive without. > > The evas_module_find_type() needed changes too to support the new > library paths. > > If I remember correct this were the biggest changes I've done until > now. > > How to bring this into EFL trunk? > --------------------------------- > My idea to solve the build structure is to create a new configure > option (e.g. --flat-lib-naming or more specific --enable-android) and > handle the magic in all Makefile.am files with this options. I even > think about auto detecting android support and just configure it in a > correct way. This would be more smart. > > The change in evas itself are only several lines of code that I > currently guard with #ifdef __ANDROID__. > > For sure all dependencies (libpng, libjpeg, freetype...) needs to be > modified in some similar way regarding the library naming. I would > maintain this as patches for release versions as long as they don't > support android. > > Next steps > ----------- > Ok, after bringing android support with current state into EFL trunk I > would start to write some software_android engine and later maybe some > gl_android engine. I assume the input events (touchscreen) then needs > also to be supported. I've really no idea how this works as I didn't > care about it currently. But I'm sure there's a way... > > Help needed > ----------- > I like to commit my changes to EFL and afterwards I hope some > tutorials and an example application could motivate someone > experienced with writing evas engines to support this port. > > So if nobody complains after this email I'll commit my changes > _carefully_ to EFL with being sure not to destroy any existing code. I'm looking forward to seeing your work. Dunno if I can help much, but I'll certainly by trying it out. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
