Peter Serwylo 2b8a882933 Merge branch 'integration/mr-102-and-107' into 'master'
Integration branch containing both MR 102 and 107

Given both MR !102 and !107 both stood on eachothers feet to some extent, this branch contains all commits from both in an integration branch. If both @Nutomic and @eighthave are happy that it faithfully kept their changes during the minor merge conflict resolutions, then we can merge this instead of those two branches. 

* !102 changed download progress from events + listeners to broadcasts + receivers.
* !107 made use of download progress events + listeners to show a downloading UI that was embedded in the activity, rather than shown as a modal dialog.

The conflicts which arose while I merged these branches together were in `AppDetails`. I made it so that, to the best of my ability, it uses broadcast receivers instead of progress listeners when updating the progress bar. Other than that, the only other conflict was both trying to store a reference to the main button from the UI. The only changes were in naming (mainButton vs btMain) and also in the place where the local variable was assigned (onCreate() vs setupViews() which is called during onCreate() anyway).

After merging, I did some minor cleanups. This is because in the process of checking that my conflict resolution compiled, I thought it best to remove a bunch of warnings from `AppDetails` and others. Turns out that by doing so, I found a bug due to the integration (to do with the `AppDetails` querying the downloader for status in `onResume()` rather than waiting for a broadcast event) so I'm glad I did so.

Let me know what you think, and then after the next stable, we can go ahead and merge this if people are happy.

p.s. I have no idea why GitLab is showing @eighthave's commit at the top of the list of commits, after my integration related commits.

See merge request !114
2015-08-09 06:09:54 +00:00
2015-08-05 16:48:45 -07:00
2015-07-04 21:17:14 +03:00
2014-12-11 13:50:05 +01:00
2015-06-16 20:05:55 +02:00
2015-07-31 17:13:42 -07:00
2015-08-04 14:37:34 -07:00
2013-04-12 14:45:48 +01:00
2015-07-25 21:02:40 -07:00
2015-07-25 21:04:32 -07:00

F-Droid Client

Client for F-Droid, the Free Software repository system for Android.

Building from source with Gradle

The only required tools are the Android SDK and Gradle.

You should use a relatively new version of Gradle, such as 2.4, or use the gradle wrapper.

Once you have checked out the version you wish to build, run:

    cd F-Droid
    gradle assembleRelease

The resulting apk will be in build/outputs/apk/.

Android Studio

From Android Studio: File -> Import Project -> Select the cloned top folder

Building tips

  • Use gradle --daemon if you are going to build F-Droid multiple times.
  • If you get a message like Could not find com.android.support:support-..., make sure that you have the latest Android support maven repository

Direct download

You can download the application directly from our site or browse it in the repo.

Contributing

You are welcome to submit Merge Requests via the Gitlab web interface. You can also follow our Issue tracker and our Forums.

Translating

The res/values-* dirs are kept up to date automatically via MediaWiki's Translate Extension. See our translation page if you would like to contribute.

Running the test suite

In order to run the F-Droid test suite, you will need to have either a real device connected via adb, or an emulator running. Then, execute the following from the command line:

gradle connectedAndroidTest

This will build and install F-Droid and the test apk, then execute the entire test suite on the device or emulator.

See the Android Gradle user guide for more details, including how to use Android Studio to run tests (which provides more useful feedback than the command line).

Versioning

Each stable version follows the X.Y pattern. Hotfix releases - i.e. when a stable has an important bug that needs immediate fixing - will follow the X.Y.Z pattern.

Before each stable release, a number of alpha releases will be released. They will follow the pattern X.Y-alphaN, where N is the current alpha number. These will usually include changes and new features that have not been tested enough for a stable release, so use at your own risk. Testers and reporters are very welcome.

The version codes use a number of digits per each of these keys: XYYZNN. So for example, 1.3.1 would be 103150 and 0.95-alpha13 would be 95013 (leading zeros are omitted).

Note that we use a trailing 50 for actual stable releases, so alphas are limited to -alpha49.

This is an example of a release process for release 0.95:

  • We are currently at stable 0.94
  • 0.95-alpha1 is released
  • 0.95-alpha2 is released
  • 0.95-alpha3 is released
  • Testing process (1-2 weeks) during which no new features are merged in
  • 0.95 is released
  • A bug is reported on the stable release and fixed
  • 0.95.1 is released

License

This program is Free Software: You can use, study share and improve it at your will. Specifically you can redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

Some icons are made by Picol, Icomoon or Dave Gandy from Flaticon or by Google and are licensed by Creative Commons BY 3.0.

Other icons are from the Material Design Icon set released under an Attribution 4.0 International license.

Description
No description provided
Readme GPL-3.0 46 MiB
Languages
Java 98.5%
Shell 0.6%
Python 0.6%
AIDL 0.2%
HTML 0.1%