Artifact Content
Not logged in

Artifact a53cd51ce8e8f1f8396adc3e12671dba52076ccb:

Nextcloud Android app

irc irc


  1. Guidelines
    1. Issue reporting
    2. Labels
      1. PR
      2. Issue
  2. Contributing to Source Code
    1. Developing process
      1. Android Studio formatter setup
    2. Contribution process
      1. Fork and download android/master repository
      2. Create pull request
      3. Create another pull request
    3. Translations
  3. Releases
    1. Types
      1. Stable
      2. Release Candidate
      3. Dev
    2. Version Name and number
    3. Release cycle
    4. Release Process
      1. Stable
      2. Release Candidate
      3. Development Dev


Issue reporting


Pull request


Bug workflow

Contributing to Source Code

Thanks for wanting to contribute source code to Nextcloud. That's great!

New contributions are added under AGPL version 3.

Developing process

We are all about quality while not sacrificing speed so we use a very pragmatic workflow.

Branching model

branching model * All contributions bug fix or feature PRs target the

branch * Feature releases will always be based on
* Bug fix releases will always be based on their respective feature-release-bug-fix-branches * Bug fixes relevant for the most recent and released feature (e.g.
) or bugfix (e.g.
) release will be backported to the respective bugfix branch (e.g.
) * Hot fixes not relevant for an upcoming feature release but the latest release can target the bug fix branch directly

Android Studio formatter setup

Our formatter setup is rather simple: * Standard Android Studio * Line length 120 characters (Settings->Editor->Code Style->Right margin(columns): 120) * Auto optimize imports (Settings->Editor->Auto Import->Optimize imports on the fly)

Build variants

There are three build variants * generic: no Google Stuff, used for FDroid * gplay: with Google Stuff (Push notification) and Analytics disabled, used for Google Play Store * modified: custom, with Google Stuff and Analytics enabled, used for branded releases

Contribution process

1. Fork and download android/master repository:

2. Create pull request:

3. Create another pull request:

To make sure your new pull request does not contain commits which are already contained in previous PRs, create a new branch which is a clone of upstream/master.


We manage translations via Transifex. So just request joining the translation team for Android on the site and start translating. All translations will then be automatically pushed to this repository, there is no need for any pull request for translations.


At the moment we are releasing the app in two app stores:


We do differentiate between three different kinds of releases:


Play store and f-droid releases for the masses. Pull Requests that have been tested and reviewed can go to master. After the last release candidate is out in the wild for ~2 weeks and no errors get reported (by users or in the developer console) the master branch is ready for the stable release. So when we decide to go for a new release we freeze the master feature wise.

Release Candidate

stable beta releases done via the Beta program of the Google Play store and f-droid. Whenever a PR is reviewed/approved we put it on master. Before releasing a new stable version there is at least one release candidate. It is based on the current master and during this phase the master is feature freezed. After ~2 weeks with no error a stable version will be releaded, which is identically to the latest release candidate.


Done as a standalone app that can be installed in parallel to the stable app. Any PR which is labelled "ready for dev" will be automatically included in the dev app. This label should only set by the main developers. Same applies for the android-library. This repository also has a branch called dev which includes all upcoming features. The dev branch on this repository must always use the android-library dev branch.

Version Name and number

Stable / Release candidate

For stable and release candidate the version name follows the semantic versioning schema and the version number has several digits reserved to parts of the versioning schema inspired by the jayway version numbering, where:

Version code schema

Examples for different versions: * 1.0.0

* 8.12.2
* 9.8.4-rc18

beware, that beta releases for an upcoming version will always use the minor and hotfix version of the release they are targeting. So to make sure the version code of the upcoming stable release will always be higher stable releases set the 2 beta digits to '99' as seen above in the examples.


For dev the version name is in format YYYYMMDD. It is mainly as a reference for reporting bugs and is not related to stable/release candidates as it is an independent app.

Release cycle

To get an idea which PRs and issues will be part of the next release simply check our milestone plan

Release process

Stable Release

Stable releases are based on the git master.

  1. Bump the version name and version code in the AndroidManifest.xml, see chapter 'Version Name and number'.
  2. Create a release/tag in git. Tag name following the naming schema:
    (e.g. stable-1.2.0) naming the version number following the semantic versioning schema

Release Candidate Release

Release Candidate releases are based on the git master and are done between stable releases.

  1. Bump the version name and version code in the AndroidManifest.xml, see below the version name and code concept.
  2. Create a release/tag in git. Tag name following the naming schema:
    (e.g. rc-1.2.0-12) naming the version number following the semantic versioning schema

Dev Release

Dev releases are based on the master branch and are done independently from stable releases for people willing to test new features and provide valuable feedback on new features to be incorporated before a feature gets released in the stable app.

The deployment/build is done once a day automatically. If code has changed a new apk will be published here and it will, with a little delay, be available on Fdroid.