Android port

From Stellarium Wiki
(Difference between revisions)
Jump to: navigation, search
('Action bar' icons)
(Known issues: + tegra devices don't work)
 
(25 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
<div class="toc">'''Note''': There is a '''paid''' [https://play.google.com/store/apps/details?id=com.noctuasoftware.stellarium ''Stellarium Mobile''] port for Android by [http://www.noctua-software.com/ 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.</div>
 +
 
Experimental port of Stellarium to Android using not-yet-complete Android port of Qt, [http://sourceforge.net/p/necessitas/home/necessitas/ necessitas].
 
Experimental port of Stellarium to Android using not-yet-complete Android port of Qt, [http://sourceforge.net/p/necessitas/home/necessitas/ necessitas].
  
Line 6: Line 8:
  
 
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.
 
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.
  
 
== Specification / design ==
 
== Specification / design ==
Line 20: Line 24:
 
=== Rough timeline ===
 
=== 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'')
 
(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  
 
* Complete first releasable QML-based GUI  
 
** <strike>Design GUI</strike>
 
** <strike>Design GUI</strike>
Line 28: Line 36:
 
*** Add button tooltips
 
*** Add button tooltips
 
*** Add View / Markings / Plugin dynamic button drawers
 
*** Add View / Markings / Plugin dynamic button drawers
**** <strike>See specification. These drawers will contain buttons added by code; buttons won't be hardcoded in the QML. This will allow for easier interaction with plugins.</strike>
 
**** I think I'm going to ignore that and, at least for the first release, do it all manually, ''including'' adding plugins (maybe I'll give plugin-added buttons their own dialog buried somewhere). I'll probably end up changing my mind tomorrow, though.
 
 
** Fix the static plugins
 
** 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
 
*** 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
 
*** 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
+
** <strike>Add pretty, Android-styled button icons
 
*** Decide on DPI buckets
 
*** 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. <code>Image{ source: "scaled://image.png" }</code>), and it'll get the image from the correct bucket
+
*** 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. <code>Image{ source: "scaled://image.png" }</code>), and it'll get the image from the correct bucket</strike>
 
** Add search
 
** Add search
 
*** ...
 
*** ...
Line 57: Line 63:
 
* Localization support
 
* Localization support
 
** Autodetect locales via JNI
 
** 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
 
** Ensure that everything in QML is translatable, and in the gettext files
 
* Accelerometer support
 
* Accelerometer support
Line 62: Line 69:
 
* Alpha testing
 
* Alpha testing
 
* Optimize
 
* Optimize
** Implement ETC1 texture compression
+
** Implement texture compression (PVR, DXT, ETC1)
*** ETC1 may have issues with large chroma shifts, which could render it useless for us. If so, may have to use device-specific texture compression formats. => more work. We may want to move that way ''eventually'' anyways
+
*** 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 OpenGL
 
** Profile with gprof or callgrind
 
** Profile with gprof or callgrind
Line 87: Line 95:
 
=== Art ===
 
=== 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.
 
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:
 
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:
Line 96: Line 106:
 
The Android GUI design guidelines are at [http://developer.android.com/guide/practices/ui_guidelines/index.html] as well as [http://developer.android.com/design/index.html]
 
The Android GUI design guidelines are at [http://developer.android.com/guide/practices/ui_guidelines/index.html] as well as [http://developer.android.com/design/index.html]
  
Android artwork can be found in the AOSP repositories. The [http://developer.android.com/design/index.html Android design] site also has vector art, but it's under a somewhat vague license (unrestricted use ''to develop your apps''). The same art is available rasterized in AOSP's repository (under the Apache license 2.0) though.
+
Android artwork can be found in the AOSP repositories. The [http://developer.android.com/design/index.html 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 <code>data/mobileGui</code> 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 ====
 
==== 'Action bar' icons ====
Line 105: Line 129:
 
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.
 
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.
+
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.
 
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.
Line 115: Line 139:
 
** Open search
 
** Open search
 
** Open controls
 
** Open controls
** Toggle accelerometer (on / off)
+
** Toggle accelerometer
 
** . . . / maximize sidebar (standard Android-style)
 
** . . . / maximize sidebar (standard Android-style)
  
Line 126: Line 150:
  
 
* [[Android_port/Specification#Playback]]
 
* [[Android_port/Specification#Playback]]
** Rewind (on / off)
+
** Rewind  
** 1x speed (on / off)
+
** 1x speed  
** Current time (on / off)
+
** Current time  
** Fast forward (on / off)
+
** Fast forward
  
 
* [[Android_port/Specification#Search]]
 
* [[Android_port/Specification#Search]]
 
** Search
 
** Search
  
* [[Android_port/Specification#Pull-down bar]]
+
* [[Android_port/Specification#Menu]]
 
** Close/minimize sidebar
 
** Close/minimize sidebar
 
** Night vision mode
 
** Night vision mode
Line 140: Line 164:
 
** Location
 
** Location
 
** Settings
 
** Settings
** Information box
+
** Sky dialog
** Objects dialog
+
*** (for enabling/disabling stars, planets, etc.)
*** for enabling/disabling stars, planets, etc.
+
** View dialog
** Markings dialog
+
*** (likewise for markings; grids, constellations, etc.)
*** likewise for markings; grids, constellations, etc.
+
** Plugins dialog
** View/misc dialog
+
*** (Plugins add their buttons to this one; could contain anything)
*** everything else. Oculars, equitorial/altaz toggle, etc.
+
** <strike>Plugins dialog</strike>
+
  
 
==== Android / Google Play art ====
 
==== Android / Google Play art ====
Line 164: Line 186:
  
 
== New issues ==
 
== New issues ==
 +
<!-- As above, the Stellarium Mobile port on Google Play is unrelated. Please don't add issues for that here. -->
  
 
== Known issues ==
 
== Known issues ==
* Performance and CPU usage need to be looked at (above)
+
* 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
* Check for NPOT texture support (driver may be returning true even if it's not)
+
* since updating, the splash screen only shows up for a moment (less than one second)
** do we care?
+
** this appears to be a common issue when building Stellarium on Windows (see mailing list)
* App should be suspended or outright killed when it's switched away from, as it continues to go full tilt and drain battery
+
 
* need to (re)disable "Zoom to Fullscreen" option on tablets
+
* Performance and CPU usage need to be looked at
* it occasionally crashes very soon after starting; usually shortly after, or even during the loading screen
+
* Check for NPOT texture support (some drivers ''may'' be returning true even if it's not)
** it ''may'' happen more frequently immediately after installing the app. The log and logcat output show nothing interesting.
+
** 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.
** this is associated with startup somehow; after the ~30 second mark, I've not seen it crash. I've had it running overnight unintentionally without instability.
+
* App should be suspended when it's switched away from, rather than waiting for Android to kill it
  
 
=== Issues waiting for necessitas ===
 
=== Issues waiting for necessitas ===
* [https://sourceforge.net/p/necessitas/tickets/120/ 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.
+
* <strike>[https://sourceforge.net/p/necessitas/tickets/120/ 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.</strike>
** there's a fix that's yet to be reviewed
+
** necessitas now has a new, official mechanism for accessing APK assets. see [http://community.kde.org/Necessitas/Assets]
* <strike>resuming the app (switching to another app, then back before Android closes it) results in a blank screen
+
** there's a not-yet-reviewed fix for this as well</strike>
+
* [https://groups.google.com/d/topic/android-qt/7rCEv7ddtmU/discussion]
+
* [https://sourceforge.net/p/necessitas/tickets/169/ issue 169] - soft keyboard always resizes window
+
  
 
== Misc notes ==
 
== Misc notes ==

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

[edit] Specification / design

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

[edit] 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.

[edit] Remaining tasks

[edit] 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

[edit] 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]

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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)

[edit] '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)

[edit] 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

[edit] 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)

[edit] New issues

[edit] 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

[edit] 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]

[edit] Misc notes

[edit] Contributing

[edit] Building

See: Building for Android

[edit] 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