3.4 KiB
AdvancedPrivacy Development Guide
This guide contains development related information to help a developer in getting better understanding of project structure.
Architecture
The architecture of AdvancedPrivacy is based on clean architecture. For presentation layer, we use a MVVM design pattern, with a unique StateFlow for each screen to simplify coherence. Our android app is having single activity multiple fragments, using Android Navigation component.
The project has 2 flavors :
- eOS: for /e/OS devices, with OS specific signatures, system priviledges and persistent flag
- standalone: for app's stores, without any priviledges.
Most of the differences between the 2 flavors are separated in distinct modules like :
- permissioneos / permissionstandalone
- trackersserviceseos / trackersservicesstandalone
Clean Architecture
Clean architecture is the building block of AdvancedPrivacy. It is now a common way of organizing project, so it helps newcomers. It gives a framework to apply Single Responsibility Principle, having a testable project and keep files with a decent length.
The detailed file tree:
Domain
- entities : data classes, with no logic
- usecases : most of the logic, with no external dependencies
LocalRepositories
Repositories of data, that use local datasources, like sqlite database, sharedpreferences or in memory objects.
NetworkRepositories
Repositories of data, which fetch and push data to some remote servers.
InterfaceAdapters
All the glue to abstract Android framework (and also all it's supported versions) from the domain layer.
- services: Android Services
- broadcastreceivers: Android Broadcast Receivers
- Android Interfaces : abstraction of framework interfaces, like private and priviledges specific API.
UI All the UI related code, with MVVM pattern.
Good practices
Use hidden-apis-stubs
Reflexion is avoided. We use an hidden-apis-stub project to make Android hidden APIs available for development and compilations. Each stubed API should be documented with link to the source code they stub, for each targeted Android version.
Use Coroutines and Flow
We use Coroutines and Flow for asynchronous tasks. The previous technologies (RxJava, LiveData) to do that are not welcome :)
Use Koin for dependency injection
The project use Koin for "DI". It's flexibility is helpful to cleanly separate the flavored modules.
OrbotService development and maintenance
The IpScrambling relies on a fork of OrbotService, which is a module of Orbot, the Tor proxy for Android. It lays as a submodule to help fork upgrade and patching. More here: orbotservice/README.md
Code Quality and Style
It use ktlint through spotless. The specific rules are defined in .editorconfig.
To run code style check and formatting tool:
./gradlew spotlessCheck
./gradlew spotlessApply
If spotlessApply fails, let's discuss to relax the ktllint rules.
State-of-The-Art
This document present the objectives for the project, some area may still have legacy code organizations.
Todo/Improvements
- Add unit tests and code coverage.