Black screen on Android about microwindows HOT 21 CLOSED

The Microwindows version in this repo will not work for Android. Please use the binary version in this repo: https://github.com/georgp24/microwindows-android-bin
Compiling that from scratch is so time-consuming and tedious that I decided to provide binary files.

In there there is an application note how to get this to run on Android:
https://github.com/georgp24/microwindows-android-bin/blob/master/doc/FLTK%20on%20Android%20application%20note.html

Georg

from microwindows.

Thanks for your prompt answer, I already checked out your second repo :)

I am trying to build a cross platform template for FLTK applications and made quite some progress so far (https://projects.nwrk.biz/projects/fltk-mvc-templ/wiki/). I wanted to avoid precompiled stuff for transperancy and portability. As I mentioned the app seems perfectly running (i can put debugg messages in logcat), but the display stays black.

Nevertheless I will try to link your precompiled libs and report back if they worked :)

from microwindows.

Here is the reicepe I used to compile: https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/packages/nanox/Makefile

from microwindows.

When linking against prebuilt -lPX11 and allegro it works :)

from microwindows.

from microwindows.

from microwindows.

from microwindows.

Daniel, I just added a Configs/config.android based on your config_android_arm into the source master. In the cleaned up tree, only the section in Arch.rules under ANDROID will need to be modified. Can you try pulling the new tree and setting that section with your CFLAGS/LDFLAGS and then running your Makefile? This will get us a long way forward to debugging the screen issue, knowing now that Georg’s binary works. I will then add the CFLAGS/LDFLAGS into Arch.rules so that we have a compiling version. If you change your Makefile to 'cp Configs/config.linux-X11 config' that should work with the new tree also. Regards, Greg
…
On Jan 31, 2019, at 5:05 PM, Daniel G. @.***> wrote: When linking against prebuilt -lPX11 and allegro it works :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5WIZDCmPJu1zshpPfXGTx1PTEJbXks5vI4SwgaJpZM4acNZV.

Thanks for your reply!

I tested your config and added my flags to Arch.rules instead of sed replacing in Makefile.rules and it compiled, but again resulting with a running app without screen output.

regards,
giri

from microwindows.

That’s great news! We need to diff the drivers/allegro5.c in his and my tree, and copy Georg’s to the master tree if different. I just described some other changes in the mainline polling mechanism that were required for the SDL2 port, and we can get the Allegro driver updated to the newer mechanism and you should then have a version you can compile from scratch. Georg - what are the reasons that you were saying that the current source master isn’t compatible with getting an Android version work? Is it just the driver files, or are there other items in the tree that are necessary? Regards, Greg
…
On Jan 31, 2019, at 5:05 PM, Daniel G. @.**> wrote: When linking against prebuilt -lPX11 and allegro it works :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5WIZDCmPJu1zshpPfXGTx1PTEJbXks5vI4SwgaJpZM4acNZV.

I already did a diff on the driver/*allegro5 files and did not find any significant changes. The only thing that changeg were some direction macros within the mou_allegro5.c file.

from microwindows.

Oh the -m32 switch is needed to compile 32 bit binaries. I do this to get binaries which can be executed on a wider range of machines :) So nothing thats really needed on a normal build.

from microwindows.

from microwindows.

I tested your config and added my flags to Arch.rules instead of sed replacing in Makefile.rules and it compiled, but again resulting with a running app without screen output.
Can you send me your modified Arch.rules? I would like your working settings. We are now testing both NX11/PX11 library and libnano-X.a. In order to reduce variables, any chance you can test one of the Nano-X demos, like demo-hello? You will need to set NANOXDEMOS=Y in your config and then possiibly edit demos/nanox/Makefile. With everything compiling, we should be able to fix things soon. There is a small chance I will have to modify the allegro driver but i think we’re backwards compatible but just not for speed. Georg contributed the Android port and knows much more about this than I do, we’re waiting for his response on why the current tree won’t support Android. Regards, Greg
…
regards, giri — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5W4zQsC_mfeInXz0uIpT9v1zD7GNks5vI5o3gaJpZM4acNZV.

I have attached my Arch.rules file, but it depends on my project structure and on debians android ndk packages.

Should i test to build the examples for android? Or just if it compiles using the android toolchain when setting the right include paths. For android the programms need to be compiled to a .so and then wrapped into a small android app executing the .so using allegro.

from microwindows.

Arch.rules.txt

from microwindows.

from microwindows.

I have attached my Arch.rules file, but it depends on my project structure and on debians android ndk packages.
Thanks, I will edit this slightly and add it so that others can build by setting ANDROID_NDK_HOME and ANDROID_PLATFORM_VER, and ALLEGRO5_INCLUDE. I think the ALLEGRO5_INCLUDE should be set in the config file.
Should i test to build the examples for android? Or just if it compiles using the android toolchain when setting the right include paths.
I would like to see you build demo-hello at least (very basic) and then see whether it runs. It likely won’t, but this at least eliminates libNX11 as a possible problem.
For android the programms need to be compiled to a .so and then wrapped into a small android app executing the .so using allegro.
If you show me a Makefile for doing that, I can add that to the tree also, similar to what was done for EMSCRIPTEN, see demos/Makefile-emscripten, Thanks! Regards, Greg
…
— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5dPvolaD6Gpk39pUHCIQ_GJLHv11ks5vI6OngaJpZM4acNZV.

I just compiled lNX11 and nano-X using georgs source tree and the resulting binaries work. (just to verify if the source matches the precompiled binaries)

Ok i will try to create a demo-hello android .apk

Creating android apps is usually done using gardle. Gardle completely sucks IMO, because it hides everything it does from you and is very painful to configure. So I created a makefile which executes all commands to pack a android app (see the very end of this file): https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/src/Makefile

from microwindows.

from microwindows.

Hooooraay thanks!! -DHAVE_SELECT=0 did the trick :))))

from microwindows.

If you want to i can try to create a little sample project to create andriod apps within your source structure.

from microwindows.

from microwindows.

from microwindows.

Bah I feel really happy right now :) The cross platform fltk MVC template project is now working on android too :D

If you are curious, i just created a fresh build:
https://buildbot.nwrk.biz/share/fltk_mvc_template/origin/dev/25/install_package/

The apk works fine on all my testing devices :)

I'll close this issue now. I think next week i have some spare time where I can try to create the andruid builds. I will send a pull request when finished if thats ok?

Thanks again for your help,
giri

from microwindows.