MuntashirAkon
commented
2 years ago Designing a unified API
Number of supported services
App Manager has to support at least the following services:
- GitHub
- Google Play Store
- F-Droid repositories
The following services should also be considered:
- Graphene OS' Apps repository
- APK Pure
Priorities of the services
Unification of multiple services in Android is troublesome due to many issues such as mismatched signing certificate, trusting the APK sources and so on. Priority of services should be decided on the basis of privacy, security, availability and trust. However, App Manager will note the installation source and will not switch or fallback to the next available service automatically. This has to be so much restricted that on the event of running into installation issues, presumably due to signing certificate, App Manager will ask the user to reinstall the app with the new signature instead of falling back to the next service. This, in general, ensures the safety of the user, and makes the multiplicity of services transparent to the system.
Here's an outline of how the priorities might work for different services:
- GitHub subscriptions will, naturally, be the top priority because GitHub, with proper channel, can be trusted (and it is already presumed that by following the repository, the user trusts the developer). However, the user needs to configure the repositories meaning unless App Manager community delivers the configurations, this feature will be mostly remain unused.
-
Certain F-Droid repositories will get the next priority. Each F-Droid repository is considered a separate service due to the nature of the repositories and will be prioritised accordingly. Example of repositories that will be prioritised:
- Bitwarden repository
- NewPipe repository
- Bromite repository
- UnGoogled Chromium repository
- Collabora office repository
- Session repository
- Briar repository
As can be seen, the repositories are prioritised because they are official and trusted, just like GitHub, and may be more privacy respecting that the Google Play Store version.
- Graphene OS Apps' repository. (Prevents overlapping with Google Play as described above) Currently, there are no other repositories that uses this scheme.
- Google Play Store, if enabled, will get the next priority. This is prioritised over the official F-Droid repository for the following reasons (sorted on the basis of importance in descending order):
- Updates are available just as the developer pushes them
- It enforces the use of safer permissions and target SDK (although it is understandable that certain tools may require lesser target SDK due to their usage)
- Use of up to date signing schemes unlike F-Droid
- The rest of the F-Droid repositories will get the next priorities. The repositories are sorted on the basis of the key reasons described above.
- IzzyOnDroid (This falls below Google Play Store because the apps found on Google Play Store/GitHub could be identical)
- F-Droid official
- Guardian project
- Calyx OS
- Divest OS
Priorities could be dynamic for certain platforms. For Graphene OS, Graphene OS' Apps repository will get higher priority. For Calyx OS, Calyx OS' F-Droid repository will get higher priority. In any case, the source of the APK will always be visible to the user so that the user may be aware of it.
One might ask why App Manager will not be supporting the addition of custom F-Droid repositories. The reasons are as follows (sorted on the basis of importance in ascending order):
- Addition of repositories is rarely used by a regular user. Many users aren't even aware of the existence of this feature.
- Most users are incapable of doing enough research to understand the catches of adding a repository. To be specific, they fail to recognise how trustable a repository might be.
- We intend to support certificate pinning which is built statically with the app itself.
Notice that this is now the searching takes place. This can easily be bypassed by supplying separate build flavours for each platform. But this is up to the developer. For example, one might choose to append .play and .fdroid to the package name for Google Play and F-Droid respectively.
Alpha/Beta/Stable
Support for beta and stable is determined by the following:
- If the API supports it, then it is used directly.
- Application of heuristics i.e. version name/app label containing
alpha,beta,rc,pre, etc.
Split APK
A wide range of APK files are supported in accordance with API (all except F-Droid supports split APK). Formats include APK, APKS, XAPK, APKM or a collection of APK files. APKs are selected based on the device configuration as usual. But the user may be prompted to select the APKs to install if enabled.
Automatic updates
App Manager would check for updates and update apps automatically using heuristics by default. Per-app auto-update can be disabled like any other clients. Example of application of heuristics: Prompt user via notification if the user jumps version code by a significant number (the number may also be determined heuristically) or updates to a major release (if the app follows semantic versioning).
App recommendations
How recommendations will be generated is still a big issue. We cannot obviously trust automated, unaudited and biased algorithms. Community recommendations/lists would be the most beneficial as our main focus is on privacy, but practicality of such approach is largely unknown.
Jrchintu
S7venLights
shuvashish76
Obegg
In App Manager, our goal, as always, is to unify features and remove the burden of using another application.
Currently, we've included Aurora Store, APK Updater and F-Droid in various pages so that the user can easily open the apps as if they are part of the app. However, this model doesn't work very well since App Manager, like any other package managers, should be the source to download, install and update applications. In order to achieve that and reduce burden on the main app, I propose another extension that merges both Google Play Store and F-Droid.
Features
Privacy features
Obstacles