
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
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.