- 1 Motivation
- 2 Potential Roadmap
- 2.1 Create fdroidclient-lib project
- 2.2 Create fdroidclient-light project
- 2.2.1 Absolute bare bones initial app for fdroidclient-light
- 2.2.2 Things which can be added after a very basic release
- 2.2.3 Things which are not required, but may be relatively easy to put in fdroidclient-lib (and thus make it easier to implement in fdroidclient-light)
- 2.2.4 Things which probably are not needed at all
The idea behind this is that as newer Android APIs come out, it becomes harder for a small team of F-Droid devs to keep pace with the required effort to provide backwards compatibility when new features or UIs are added.
While we currently consider very carefully whether to increase the minimum required Android version for F-Droid, it still occurs from time to time. Examples include:
- Dropping support for v3 after the Android Support libraries were released and only went back to v4.
- Dropping support for v4, 5, and 6 when it became apparant the Android developers were keen to support major UI features only in the Support v7 library (though appcompat).
- Dropping support for v8 when it became apparant that new Java 1.7 language features were not going to get supported on earlier devices. There was also significant improvements to the entire Android SDK in version 8, resulting in many work-arounds to write code that works on v7.
As you can see, there is already a bunch of devices (earlier than v8) which cannot use newer versions of F-Droid. Also, it is not impossible that in the future, the minimum required Android version will increase again.
There are three options:
- Ignore older devices, point them to the last working version of F-Droid for that device.
- Ensure that all new features work on both newer and older versions of Android.
- Provide a minimalistic version of F-Droid that works on _all_ devices, but is not very feature rich.
Option 1 is undesirable, because security fixes will not be backported to older versions.
Option 2 is difficult primarily due to the small development team of F-Droid (at any one time, there may be between one and five people committing code).
Option 3 is advocated by this proposal.
Create fdroidclient-lib project
Refactor the shared code (e.g. updating repositories and database handling) into fdroidclient-lib.
This should at least include include:
- Repo updating
- App/Apk/Repo value objects
- Content providers
This may or may not include, due to the use of newer APIs:
- Downloading repos/apks
Create fdroidclient-light project
This is just some thoughts on how it _could_ be done, but anybody willing to work on this is of course free to work on it however they want.
Absolute bare bones initial app for fdroidclient-light
- Update from the F-Droid repo (using code from fdroidclient-lib)
- Show a list of apps from the repo
- Don't worry about icons (as they need to be downloaded)
- Touching an app could give the relevant options: Install, Update, Remove
Things which can be added after a very basic release
- Searching for apps
- Adding repos
- Viewing details of apps
- Showing installed apps
- Update notifications
- Incompatible apps
Things which are not required, but may be relatively easy to put in fdroidclient-lib (and thus make it easier to implement in fdroidclient-light)
- App cache
- Proxy/TOR support
- Ignore Updates
Things which probably are not needed at all
- Swapping apps
- System installer
- Bluetooth and NFC app sharing
- Multiple themes