Android port

From Stellarium Wiki
(Difference between revisions)
Jump to: navigation, search
(Rough timeline: shader loops need to be made unrollable)
(Known issues: + tegra devices don't work)
 
(One intermediate revision by one user not shown)
Line 189: Line 189:
  
 
== Known issues ==
 
== Known issues ==
 +
* Tegra devices no longer work. The only ''currently-known'' Tegra issue is that there are non-unrollable loops in a couple of the shaders, which aren't supported
 
* since updating, the splash screen only shows up for a moment (less than one second)
 
* since updating, the splash screen only shows up for a moment (less than one second)
 
** this appears to be a common issue when building Stellarium on Windows (see mailing list)
 
** this appears to be a common issue when building Stellarium on Windows (see mailing list)
* sometimes, the QML GUI seems to have the wrong screen size and doesn't update. I'm not sure if this is a Necessitas issue at this point; not only does the GUI not scale to completely cover the screen, but touches within the GUI have the wrong x and y coordinates.
 
  
 
* Performance and CPU usage need to be looked at
 
* Performance and CPU usage need to be looked at
* Check for NPOT texture support (driver may be returning true even if it's not)
+
* Check for NPOT texture support (some drivers ''may'' be returning true even if it's not)
** do we care?
+
** Not certain of this any longer. It may have been a necessitas issue rather than a driver one; on the same device, it's no longer an issue.
 
* App should be suspended when it's switched away from, rather than waiting for Android to kill it
 
* App should be suspended when it's switched away from, rather than waiting for Android to kill it
* need to (re)disable "Zoom to Fullscreen" option on tablets
 
  
 
=== Issues waiting for necessitas ===
 
=== Issues waiting for necessitas ===

Latest revision as of 05:35, 2 January 2013

Note: There is a paid Stellarium Mobile port for Android by Noctua Software. Noctua Software was established by Fabien Chereau, who is the original author of Stellarium, and his brother. Stellarium Mobile is Fabien's fork/port of Stellarium which was originally created for Nokia smartphones. Said app is not related to the port discussed on this page; this port is being developed with the intention of being merged into Stellarium-proper and becoming an official Stellarium.org-supported port, or at the very least staying up-to-date with any changes made to the official version of Stellarium and deviating from it minimally.

Experimental port of Stellarium to Android using not-yet-complete Android port of Qt, necessitas.

This is an experimental branch built on an incomplete library and is not yet ready for public consumption.

An official public release won't happen until some time after necessitas reaches Beta, and this port is sufficiently mature, whichever comes later; testing releases will probably start well before then.

You can build it at any time, though (see: Building for Android). If you want to help out in any way with development, it would be appreciated.

This page is development-centric right now; most of this will have to be spun off into another page at some point.

Contents

Specification / design

See: Android port/Specification for a detailed breakdown of the current design. Technical implementation details are broken-up into tasks below.

Communication

  • IRC channel: #Stellarium on freenode. Webchat client: [1]
  • Development mailing list: [2]
  • Feedback forum
  • Please don't submit bugs related to the port to Launchpad yet. Add them to the Wiki under New Issues, and/or pop on IRC. Anything that seems incomplete probably is.

Remaining tasks

Rough timeline

(This is a rough timeline / list of remaining feature tasks; some completed items may be in here, most not. Bugs and general issues are below, and slot into the timeline somewhere)

(I took a break. I'm active again, but Stellarium advanced quite a bit in the mean time, and some things broke when I merged these changes into my branch. I've readded ES 2 support and have to readd input/actions and look at a potential crash, but I'm just about back to the list again)

  • Make all shaders' loops unrollable (Tegra compatibility, performance, etc.)
  • Complete first releasable QML-based GUI
    • Design GUI
    • Get GUI basically operational
      • Hook QML up, and a non-functional UI minus configuration dialogs
      • Pinch-zoom
      • Get a the main GUI view actions doing something (playback, accelerometer (not hooked up, but maybe print something))
      • Add button tooltips
      • Add View / Markings / Plugin dynamic button drawers
    • Fix the static plugins
      • Some don't support ES 2. Based on IRC discussions, these plugins should be, whenever possible, doing their drawing through StelPainter and not accessing OpenGL directly
      • plugins know too much about the GUI; they access the concrete StelGui directly to create buttons, rather than the abstract StelGuiBase
    • Add pretty, Android-styled button icons
      • Decide on DPI buckets
      • Add a custom image provider for icons. This image provider will choose the correct icon based on the DPI bucket we're in. This process will be transparent to QML; all it needs to do is use use this image provider (e.g. Image{ source: "scaled://image.png" }), and it'll get the image from the correct bucket
    • Add search
      • ...
    • Add settings screen
      • Create item types, a view, and a basic model
      • Hook items up to backend
      • Refine items, view and model
      • Have multiple list views working, along with categories
      • Complete the models (with most necessary settings)
    • Add locations screen
      • A specialized settings screen with a little image of the Earth and such
      • Design
      • Implement
      • Hook up to GPS/location/(orientation?) plugin
        • Plugin doesn't exist yet. QtMobility's location support looks like it supports desktop OSs, so this plugin would be useful for more than just mobile
    • Cook up additional layouts (small phone, 5" tablet, 7" tablet, 10" tablet)
      • Design
      • Implement
  • Add Android art (icon, replace necessitas' splashscreen, etc.)
  • Consider beginning preliminary ("pre-alpha") testing
  • Localization support
    • Autodetect locales via JNI
      • This works; however, we need to manually fall back when we don't have the language+country, as this isn't handled by libintl-lite. For instance: if the locale requests "fr_CA" (which doesn't exist), we should fall back to "fr" (sans country code). Currently it just fails and falls back to "C" (English/US, the default)
    • Ensure that everything in QML is translatable, and in the gettext files
  • Accelerometer support
  • Fix large bugs and feature requests from pre-Alpha
  • Alpha testing
  • Optimize
    • Implement texture compression (PVR, DXT, ETC1)
      • PVR and DXT are device-specific (PowerVR and Tegra, respectively)
      • ETC1 may have issues with large chroma shifts, which may make it of limited use. IIRC, it also lacks an alpha channel; a shader to handle alphas stored in a second texture would be necessary
    • Profile OpenGL
    • Profile with gprof or callgrind
    • Optimization ideas:
      • Consider ways of reducing per-frame accuracy for performance/battery use boost (value caching, lerping and dead reckoning instead of recalculating constantly)
  • Fix most Alpha bugs, any particularly large ones
  • Implement big/easy Alpha feedback
  • "Beta" test
    • Dependent on Necessitas hitting Beta; until it does, spin around 'alpha' versions
  • Implement beta feedback items
  • Fix as many bugs as is feasible
  • Add remaining Android art: all Google Play-required items (banners, large icon, etc.)
  • (Eventually) - First public Google Play / other sources release, followed by bug fixing and more bug fixing

Other tasks

  • add-ons (additional catalogues and such) downloadable via Google Play to reduce bandwidth load from Android users?
  • [3] control the back key
  • find the correct location for the user's External Storage via JNI
  • location and orientation support
    • scientes suggested on IRC that we might create a multiplatform Location plugin, using QtMobility's Location API. This API appears to support desktop as well as mobile clients.
      • the location API should supported by necessitas, but may require some minor Android-specific hacks. See [4] and [5]

Art

The following art is needed. Each section of art is accompanied with a link to the specification page describing what that piece of art is used for.

Raster artwork

Note that 1dp = 1px at 160dpi. Google recommends using a 3:4:6:8 scaling ratio for assets for screens of different densities; this means we'll end up having 4 sets of most every piece of art; to convert from dp to pixels for each of the groups:

  • 0.75x
  • 1.0x
  • 1.5x
  • 2.0x

The Android GUI design guidelines are at [6] as well as [7]

Android artwork can be found in the AOSP repositories. The Android design site also has vector art, but it's under a somewhat vague license (unrestricted use to develop your apps). Much of the same art is available rasterized in AOSP's repository (under the Apache license 2.0) though.

Vector artwork

Vector artwork (in SVG format) can also be used. In that case, one can include them for as many of the above groups as desired. Simple icons may just be one image; more complex ones might have a simpler fallback for lower-DPI screens so that they don't end up as a blur.

Art grouping

Currently, the art resides in data/mobileGui in the following directories:

  • images-ldpi (low DPI; 0.75x scaling factor)
  • images-mdpi (medium DPI; 1.0x scaling factor)
  • images-hdpi (high DPI; 1.5x scaling factor)
  • images-xhdpi (extra-high DPI; 2.0x scaling factor)
  • images (used as a fallback if no images were found in the above directories; most vector art is here)
  • images-nodpi (non-scaled images; images here shouldn't have duplicates in the above directories)

'Action bar' icons

The current thought is to imitate Android's Action Bar to provide a layout that's consistent with other Android apps. Standard size for an Action Bar icon in Android 4.0, according to the Android Design guidelines, is 32dp x 32dp.

The Action Bar itself is 48dp high.

The Action Bar logo (see Android_port/Specification; the icon on the far-left of the bar) should be larger than the other icons. It can be the same size as the launcher icon. In fact, it can be the same image as the launcher icon, or it can be a variant with larger margins, whatever works best.

There's more details in the guidelines, but Google says they should be flat (not shaded, outlined, or shadowed), pictographic, and #ffffff at 80% opacity (*** I think it's a good idea if we just do the opacity programatically. Make the image 100%, have Stellarium do 80% or 30% depending on if it's enabled or disabled. Halves the number of images we need to bother with...). If we diverge from that, we should keep things consistent.

If we're doing activated/deactivated icons like Stellarium does, the deactivated ones should probably still be fairly bright (near or at #ffffff). Mobile devices vary in screen quality, and are frequently used with low brightness settings and in adverse lighting conditions.

Icons. 32dp unless otherwise noted, and all four sizes are needed (see above):

  • Android_port/Specification#Object_selected
  • (these should probably be shadowed or outlined as they don't have a background behind them)
    • Deselect object
    • Center on object
    • (Center and zoom to object?)
    • Toggle info (two states: brief / long)
  • Android_port/Specification#Menu
    • Close/minimize sidebar
    • Night vision mode
    • Date/Time
    • Location
    • Settings
    • Sky dialog
      • (for enabling/disabling stars, planets, etc.)
    • View dialog
      • (likewise for markings; grids, constellations, etc.)
    • Plugins dialog
      • (Plugins add their buttons to this one; could contain anything)

Android / Google Play art

[8]

This time, all sizes in pixels and only one size needed unless otherwise noted

  • Launcher icons (48dp; need all four sizes, so 36px, 48px, 72px, 96px)
  • High Resolution Application Icon (512x512, 32-bit PNG with alpha; Max size of 1024KB)
  • Promotional graphic (optional) (180w x 120h, 24 bit PNG or JPEG (no alpha), Full bleed, no border in art)
  • Feature graphic (optional) (1024w x 500h, 24 bit PNG or JPEG (no alpha) with no transparency; all important elements within 924x400 safe zone in center of image

Other art

  • Qt splashscreen (any size)
    • the same size as the normal splash is probably fine; 512x512. Or anything smaller. Or larger, even. Will be placed in the center of the screen and scaled down uniformly until it fits in view
    • this is shown before the normal Stellarium splashscreen, but this one doesn't have a version # or anything else on it that isn't baked-in (so yes, we get two splash screens, so this should probably not be a repeat of the other one)

New issues

Known issues

  • Tegra devices no longer work. The only currently-known Tegra issue is that there are non-unrollable loops in a couple of the shaders, which aren't supported
  • since updating, the splash screen only shows up for a moment (less than one second)
    • this appears to be a common issue when building Stellarium on Windows (see mailing list)
  • Performance and CPU usage need to be looked at
  • Check for NPOT texture support (some drivers may be returning true even if it's not)
    • Not certain of this any longer. It may have been a necessitas issue rather than a driver one; on the same device, it's no longer an issue.
  • App should be suspended when it's switched away from, rather than waiting for Android to kill it

Issues waiting for necessitas

  • necessitas bug #120 prevents us from using the package's Assets directory, as we would ideally do. For now, manually copy the files that get placed in stellarium/android/java/assets to /sdcard/stellarium on the device.
    • necessitas now has a new, official mechanism for accessing APK assets. see [9]

Misc notes

Contributing

Building

See: Building for Android

Contributing

Right now, the main thing I need is development help. Please feel free to lend a hand; create a branch off the current one (see Building for Android) and go to town. Read above for means of communication.

Translators and testers will be needed at some point.

Personal tools
Namespaces
Variants
Actions
in this wiki
other languages
Toolbox