WIP: Fixes for running on Android

[DreamNik]

Hi! I've managed to adapt Stellarium to run on Android. This is not a port, like Stellarium Mobile. It's fully-featured Android version, with some minor fixes to source. This pull contains fixes, that allows main source code to successfully compile and run on Android.

The main changes are:

1. The tab switching is changed to QTabWidget instead of QStackedWidget + QListWidget
2. Some UI modifications (moved some elements around inside dialogs)
3. Fixes, that allow building and running on Android (like renaming files .gz" to ".gzip", plugins naming and search path, Android gnustl compatibility, etc...)

The building is done NOT by using bundled CMakeList, since it requires some APK-bundling tools. I've been using QtCreator and custom ".pro" files to successfully built Stellarium for Windows-x86, WIndows-x64, Android-armv7a, Android-x86. Currently, i'm not including ".pro" files into this pull request. Here's link, if someone would want to test: https://drive.google.com/open?id=1Hh-tm-vt57A6Vb92_AxWld_Oj9TV90fx

To build:

1. Install Qt 5.9.6 (not newer, since QtScript is deprecated) with Android-armv7a or Android-x86, and MinGW compiler.
2. Install Android SDK (any version will do, but recommended v21)
3. Install Android NDK (10e or newest)
4. Modify paths in "_config.pri"
5. follow recommendations in "_config.pri" to avoid some bugs(?) in qt/ndk/sdk
6. Happily use Stellarium with all the features! (except LogBook, of course)

[gzotti]

Looks interesting. However it will take some time for me to install some SDKs first. You mention "QtScript is deprecated". Indeed, but this does not mean it's broken. Have you tried with current Qt5.11? (QtScript is an extra installable option.)

[alex-w]

This patch broke compilation Stellarium on Windows.

[alex-w]

@DreamNik why you did change the GUI?

[DreamNik]

Have you tried with current Qt5.11?

Now it works :) Got one error, fixed in last commit.

This patch broke compilation Stellarium on Windows.

Now fixed. There were multiple "CustomProxy" classes all in global scope. Moved them into parent classes scope. Should be ok now.

why you did change the GUI?

Couple of reasons.

1. Use tab bar. I just felt like it were easier to use tab bar than to re-implement current QListWidget+QStackedWidget based method with adjustments to size. Why in the first place QTabWidget weren't used for tab switching?
2. Some UI elements moved around for better screen space utilization on phone screen.
3. Android style is just "no-style" right now. It looks like default Windows-styled buttons and checkboxes on Android. Haven't got time right now to correct all the CSS widths, sizes and margins for larger style.

[DreamNik]

The one major problem, that I haven't tried to solve is touch and gestures. It works right now. Both pan and pinch (zoom). But it doesn't feels natural. The gesture recognition and event handling need to be heavily modified for this to work (or not). The desktop-like GUI on smartphone is much more harder to use (but possible,indeed!) than non-natural pan and zoom.

[alex-w]

Couple of reasons.

1. Use tab bar. I just felt like it were easier to use tab bar than to re-implement current QListWidget+QStackedWidget based method with adjustments to size. Why in the first place QTabWidget weren't used for tab switching?

Because we want to get a compact menus for make it usable on small screens also. After your changes width of menus was increasing average on 150-190%. See examples:

The window Location catches around 40% of scape on my monitor with 1920x1080 resolution. Our GUI already oversized and after your changes it will be unusable on 70-80% of desktops.

Using sliders on right side of menu bar? No problem, but we should explain many (I fear what number of angry users will be) users how long size of menus and how it should be used now.

2. Some UI elements moved around for better screen space utilization on phone screen.

Sorry, but murdering the GUI for all desktops just for good screen space utilization on hi-res phone screens is not very good reason for cardinal changes of the GUI.

Just for understanding - the mobile edition of Stellarium has same core and separate GUI (in comparison with desktop edition). Yes, the modern desktop edition has core 0.18 and mobile edition has core 0.13. Difference in the GUI by and large.

3. Android style is just "no-style" right now. It looks like default Windows-styled buttons and checkboxes on Android. Haven't got time right now to correct all the CSS widths, sizes and margins for larger style.

Obvious way: creating a special GUI for Android and switch the compile of the GUI by selection of target platform.

[DreamNik]

The window Location catches around 40% of scape on my monitor with 1920x1080 resolution. Our GUI already oversized and after your changes it will be unusable on 70-80% of desktops.

Using sliders on right side of menu bar? No problem, but we should explain many (I fear what number of angry users will be) users how long size of menus and how it should be used now.

Ok, agree. Reverted that.

Sorry, but murdering the GUI for all desktops just for good screen space utilization on hi-res phone screens is not very good reason for cardinal changes of the GUI.

No murders here. Changes are made with compatibility in mind between both of the worlds. This means, that while looking basically the same on desktop, it should be automatically adjusted to phone by using QSS only.

Obvious way: creating a special GUI for Android and switch the compile of the GUI by selection of target platform.

That's Stellarium Mobile. But I wanted alongside fully-featured version. Well, maybe not so elegant and comfortable to use.

In the last commits I've reverted the the previous changes. New modifications shouldn't change UI more than just a little bit.

So, the most changes are on this screen:

before:

after:

But how much better it's on android:

before:

after:

If you don't like this layout, tell me. But the buttons at bottom are waste of vertical space, which is limited on almost all devices.

[MasterPIC]

What about starting to publish Android releases?

[gzotti]

@MasterPIC Alexander and I are no Android developers. I am interested in finding time to test this on my €100 7" Android 4.4 tablet, but have never installed anything related to Android development. And we both have daytime jobs. I have installed Android Studio last weekend, and will continue to find out what has to be done now. If everything works and these changes do not break the 3 desktop versions, we could consider this. But it also needs changes in the automatic build system and elsewhere, and depends on a few other factors, so I do not promise anything here.

[MasterPIC]

@gzotti And what about sharing somewhere in the meantime your current Android release? I'd like to have Stellarium working on my smartphone but I've no development experience on Android :( Thanks again!

[gzotti]

@MasterPIC There is no free "current Android release" by this team. Maybe it was not clear from above, but like you, " I'd like to have Stellarium working on my smartphone but I've no development experience on Android :("

You can fight through the instructions above and write your observations as complete beginner into the wiki to help other developers without any Android developing experience. Don't forget download URLs, instructions where to find commands in the IDE menus, whatever.

If you also don't want to help, there is a very affordable Android release available in the Android store.

[DreamNik]

Here you can download some current latest android builds:

https://drive.google.com/open?id=1zP6JEOuF4vbsziwofh6mfUDt5HZKaSbh

I'm using WQHD version (Samsung S7).

If you using other lower resolution devices, you can try HD version. But this will likely to be unusable, dut to too large or too small GUI, but still launch and work.

Android API version 16 required, so any Android since 4.1.x should work.

This builds are from latest master branch, so bugs may apply :)

[MasterPIC]

@DreamNik Thank you so much! I'm using the HD version and I'm really impressed. As you already stated GUI controls are too small but, once configured, it's a real pleasure being able to use Stellarium on a smartphone. Thank you again!

[MasterPIC]

I just found star catalog updates not possible (libQt5Core.so: unauthorized access to libssl.so and libcrypto.so). Tested on Android 8.0.0.

[gzotti]

Thanks @DreamNik for the APKs. I tried the HD on my Phone. It works so far, but indeed the GUI is awkward/unusable. Buttons far too small to hit reliable, and GUI panels too large. There are many "serious" devices (7" tablets) around with resolutions probably starting at 1024x600, is there a way for you to support those?

[gzotti]

@DreamNik a few observations of somebody not regularly using Android software:

• on both my phone (FullHD, Android 7) and 7" tablet (Android 4.4, 1024x600), any GUI panel ignores the usual Stellarium GUI style (gray panels with black headers). Is this normal? Calling the (usually small) time panel overlays the Stellarium scene in fullscreen white, and shows a small window (size as expected, though) with the two tabs of the time panel. Of course, on the tiny screen the elements for mouse operation cannot be operated reliably with finger touches.
• It also seems that the main GUI buttons do not consume touch events, as I often select objects rather than press buttons. Is there something equivalent to right mouse click to unselect and get rid of the object info text?
• The Oculars screen menu gets distorted somewhat. The icons are OK, but the space between icons is larger than normal, and the config button is partially off-screen.

I don't know whether all this can be solved with a tiny modification to the regular GUI, or would require a fully new build variant with STELLARIUM_GUI_MODE=Android which should be optimized for pure touch interaction (i.e., buttons of reasonable size, and obviously GUI panels with different layout to survive on mid-res screens). This may also require a few more main GUI buttons to replace keyboard hotkeys. This looks like a lot of work...

[lusiaold]

Great job! It's running successfully on my LG G6. There are two things that could be fixed:

• FoV calculator panel doesn't show every button
• menus (like in localization settings) are somewhat hard to navigate
• GPS localization doesn't work on my device

I have no other issues than these minor ones 😀

By the way, why does the app request microphone permission?

[axd1967]

By the way, why does the app request microphone permission?

This is probably due to indirect libraries; but it is indeed a little bit smelly.

[axd1967]

For those interested: https://doc.qt.io/qt-5/android.html

[ultrapre]

@DreamNik Hi, how to build a WQHD version? The features seems to be not in the files you shared, and I can only build a HD version with smaller GUI.

[DreamNik]

Unfortunately, the question is not how to build WQHD but how to build HD version. The "HD" version had different GUI scaling. I'm currently thinking to revive the branch and implement some king of "pinch-to-zoom" DPI-independent interface.

[ultrapre]

Unfortunately, the question is not how to build WQHD but how to build HD version. The "HD" version had different GUI scaling. I'm currently thinking to revive the branch and implement some king of "pinch-to-zoom" DPI-independent interface.

Well, maybe I mix up. It seems that the difference between building HD and WQHD is on main.cpp? How to build a HD Ver? The WQHD is difficult to handle. And, the dialog window will takes up the entire screen, logic different from PC.

[DreamNik]

I neither tried to run or saved the "HD" sources. As far as i remember, first this is to edit default_cfg.ini properties "screen_font_size" and "gui_font_size".

[DreamNik]

Please, keep in mind, that last versions of this branch do not intended to change GUI in any way to be more usable on mobile platforms. Hitting some buttons (like "pin" buttons in bottom left corner) is practically impossible on most devices! Whole purpose is to run fully-featured desktop version as is. For mobile-friendly apps, search Play Store.

But I've recently started implementing plugin for drag and pinch-to-zoom functionality to be able to zoom in into some part of screen and hit small GUI elements. Also, two more plugins are in development: GPS realtime position plugin and sensor fusion plugin. But these features are still in early stages of development, although basic functionality works ok. Those plugins won't be on this branch, anyway.

[gzotti]

CMakeLists provides a STELLARIUM_GUI_MODE option (=>Standard|None). In the last decade or so it was always set to Standard, so I don't even know if None provides a meaningful result. But here would be the point to develop a completely new QML GUI with touch-friendly elements better suited for mobile devices. However, the current application is desktop-centered (mouse/keyboard) and some modules are very deeply interconnected with GUI classes, so this will be a huge effort.

About GPS positioning, see what exists in the Location dialog. This is deliberately one-shot, though.

For a cleaner history, please don't merge-in master, but rebase from master.

[DreamNik]

so this will be a huge effort.

Yes. Especially maintaining two separate GUIs. So it's much easier to run desktop GUI as-is with extended touch control capabilities. That's what I'm experimenting with.

About GPS positioning, see what exists in the Location dialog.

Yes, that's first thing I did. There is QNmeaPositionInfoSource and libgps. I'm thinking of using Qt's QGeoPositionInfoSource API. And there is no need to constantly re-position manually. Just to enable plugin and forget. It'll try to lock satellites on startup, and then refine location every, say, 5 minutes.

For a cleaner history, please don't merge-in master, but rebase from master.

I never used that technique in production. Need some time to examine it...

[gzotti]

https://github.com/Stellarium/stellarium/wiki/Git-Contributor-Workflow

It takes some learning, but is better in the long run.

[ultrapre]

Thanks for new adjust in code.The compilation and test of android_fixes branch passed. Just except the ASCOM part in telescope control plugin because of some unfound lib in ndk. Now it can run like real PC form such as dialog. I add sensor module from stellarium mobile into it and it also run well.

The gui controls and dialog window in the code are very closely related to the processing logic, and it is difficult to decouple it. It may happen that modifying one logic requires modifying two sets of codes at the same time. In contrast, it is more feasible to modify the gui in the new branch to improve the applicability to android(such as resize the left button), and keep tracking the latest features of pc version, but not to pr to master branch. Of course, more effort for a set of gui/qml mode will be more attrative.

[alex-w]

It may happen that modifying one logic requires modifying two sets of codes at the same time.

It was implemented in past time, but we removed this code, because Symbian is dead a long time ago. Plus not all elements of GUI and related logic is needed for mobile devices.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.