# FDE.AI-docs: the documentation behind the FeraDroid Engine > FDE.AI-docs is not the tuning tool itself but the place where its texts live: an information page for the root path and another for the non-root path, a kernel blocklist, an end user licence agreement, a frequently asked questions file, a set of compressed payload archives, and the update manifest that a device reads to decide what to install. **feravolt/FDE.AI-docs** — Various FDE.AI related texts - Repository: https://github.com/feravolt/FDE.AI-docs - Stars: 689 · Forks: 48 - Language: HTML - License: not declared - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/feravolt-fde-ai-docs ## A repository of texts, not of code FDE.AI-docs is described in one line as various texts related to FDE.AI, and the repository listing is the most honest description of what it holds. There is a readme, an information file, a second information file with a different suffix, a core information file, a frequently asked questions file, an end user licence agreement, a changelog, a third party notices file, and a kernel blocklist. There is a directory of app strings, a directory of root material, a directory of screenshots, and a directory that looks like it holds versions. There is a set of compressed archives with distinct names, and an update manifest written as JSON. The primary language is recorded as HTML, which is a hint about the nature of the repository: the payloads are web documents and the text files are the user-facing documentation, with images for the screens. The releases are the second clue. The version numbers are date based, with a 26.08.1 release published on 2026-08-19, a 26.05.3 from 2026-05-22, and a 26.02.3 from February 2026, and the tags are named after the product rather than the repository, with a prefix and the same version number. A repository that publishes dated releases of documents and payload archives is a distribution point, not a source tree. The readme itself is a single dense paragraph with links out to the information document, a screenshots directory, and the latest release, plus an image that is generated rather than committed, which is the kind of detail that only shows up if you look at the raw readme. ## The claim: every device gets its own parameters The FeraDroid Engine, abbreviated FDE, is described as an all-in-one optimizer for devices running Android, and the design claim is in the second sentence. Every parameter is individual for each device, depending on its hardware and software characteristics, and the parameters are described as balanced, so that you may gain performance without increasing power consumption, and reduce power consumption without losing performance. That double claim is the whole product statement: the tool does not offer a faster mode or an efficient mode, it claims to move both at once by choosing the right value for the device in front of it. The compatibility claim is broad. It is described as totally compatible with a very wide range of devices and Android versions, and the settings it applies span both the operating system and the Linux kernel underneath it, while remaining a cross-platform utility. The consequence of that design is stated too. FDE.AI applies its configurations according to the hardware and software of the device, so that in the end every device is configured individually. A per-device configuration is the opposite of a profile you download, and it is the reason a documentation repository exists at all, because the thing that has to be explained is not a set of switches but a policy for choosing values. The last clause of the claim is the one a careful reader should stop on. Some app features may not be supported on various CPUs and kernels. A tool that configures the kernel and the operating system per device will, on some hardware, turn off something an app depends on, and the documentation says so in one line. ## Systemless changes, and two ways to get the privilege The paragraph names the mechanism of the changes and the privilege levels that can apply them. All applied changes are systemless, and the parenthesis defines it: the system partition is not touched. That is the constraint that makes the tool installable on a phone that people care about, because a stock system partition is what a warranty service restores, and a tool that leaves it alone is a tool that can be uninstalled by going the other way. The privilege levels are given as two modes, root and Shizuku, with the second marked as the non-root one. That is the important detail for anybody deciding which to use. The root mode is the older, more capable path, and the non-root path relies on Shizuku, which is the non-root path named in the readme. A non-root mode is a real constraint rather than a feature label. Whatever the tuning needs to write, it can only write where Shizuku can write, so the two modes do not necessarily have the same reach, and the documentation splits its information into two files, one for each path, with matching images. So the pairing of the two things in the repository listing is deliberate: an information file for the root path and one for the non-root path, and two images that go with them. A reader who has not decided which mode they will run should read the non-root file first, because that is the one with the tighter limits. ## The kernel blocklist, and the other small files A few of the files in the listing are worth a sentence each, because their names say more than their contents are given here. The kernel blocklist is the most interesting. A tuning tool that configures the kernel per device will necessarily disable some kernel features, and a file that lists what is blocked is the document that makes that auditable. It is the file to read first if you are deciding whether the tool will interfere with something you rely on, and the place to look if a feature stops working after you install it. The end user licence agreement is present, which is worth noting in a repository whose licence field is not classified, since the terms of the tool live in that file rather than in the repository metadata. The third party notices file is the companion to it, covering the components the tool incorporates. The frequently asked questions file and the core information file are the two documents a new user reads first, with the frequently asked questions one presumably answering the questions the information document raises. The app strings directory is a small thing with a clear purpose. An optimisation tool that changes how the system behaves usually has to change strings, either the labels of system settings it hides or the messages it prints, and shipping those as a directory of translatable files rather than as constants in a binary is the difference between a tool that can be localised and one that cannot. The changelog and the update manifest complete the set, and they are the two files that describe the lifecycle of a release rather than the behaviour of a feature. ## The archives, the update channel, and the version numbers The repository carries several compressed archives with distinct names, and the documentation available here does not say what each one contains. That is worth stating plainly rather than guessing at. The names are distinct words, and there are enough of them that they are clearly separate payloads rather than duplicate archives of the same thing, but the readme and the linked information file do not enumerate them, and this repository is a collection of texts rather than a document that explains its own structure in full. The information document linked from the readme is where that mapping would be, and it is the first file to read if you want to know which archive applies to a given mode or device. The update manifest is the more revealing file. A JSON document in a repository like this is what a device fetches to learn that a new version exists and what to download, and the fact that it lives in the repository next to the release assets means the update path is the same path as the download path, with no separate server in between. The presence of a versions directory alongside it suggests the same thing, that the manifest points into a directory of published versions. The version numbering explains the release cadence. The numbers are a year and month followed by a patch count, so 26.08.1 is the first patch of the August 2026 release, and the three releases in the history are one per quarter at first and then closer together, with the February release carrying a tag whose number does not match the release it names. The date based numbering is a deliberate choice for a product that ships configuration for a moving target. Android versions and kernels change on their own schedule, and a scheme that encodes the date tells a user on an old device how far behind they are without needing to read a changelog. ## What this repository does not tell you There are gaps, and a reader should know where they are before they install anything on a device. The device list is not here. The compatibility claim is a very wide range of devices and Android versions, and the actual list, if it exists, is in the linked information document rather than in the readme. So the first practical task for an evaluator is to find the list and check that the device in hand is on it. The individual settings are not here either. The readme says that every parameter is individual for the device and that the configurations are applied according to its hardware and software, and the settings themselves are in the information document. That document is the place to find out what will actually be changed. The archives are not described, as covered above, and neither is the mapping between them and the two modes. The screenshots directory shows what the tool looks like, which is useful for judging the interface and useless for judging the behaviour. And the source is not here. This repository holds documents, images, archives, and a manifest. Whatever the FeraDroid Engine is written in, and whatever it does to the device, is not visible in this tree, which is a legitimate thing for a distribution repository to be, and it is also a limit on what a reader can verify before running it. What a reader can take away is the shape of the product and the shape of its documentation. A per-device tuning policy, applied systemless, in two privilege modes, distributed through a manifest, documented in a small number of text files that a maintainer updates on a dated release cycle. Whether the tuning is any good is a question for the device, and the kernel blocklist and the settings file are where that question is answered in detail. ## Conclusion FDE.AI-docs fits a reader who wants to know what the FeraDroid Engine claims to do, which settings it applies, and how a device is told that an update exists, before installing anything on a phone they care about. It does not fit a developer looking for the tool's source code, because this repository holds documents and archives rather than an implementation. Verify first whether your device is covered by the compatibility claim, since the documentation describes a wide range of devices without listing them, that you understand the difference between the root and the non-root mode before choosing one, because the two information files are separate documents and the non-root path uses Shizuku rather than root, and that you read the kernel blocklist, since a list of blocked kernel features is the place where a tuning tool can quietly remove something you needed. ## FAQ ### What is FDE.AI? It is the FeraDroid Engine, described as an all-in-one optimizer for devices running Android. Every parameter is chosen individually for the device according to its hardware and software characteristics, and the changes are applied systemless, so the system partition is not touched. ### What is in the FDE.AI-docs repository? Documents and distribution files rather than code. There is an information file for the root path and one for the non-root path, a core information file, a frequently asked questions file, an end user licence agreement, a changelog, a kernel blocklist, an app strings directory, several compressed payload archives, a versions directory, and the update manifest in JSON. ### What do the two modes in FDE.AI mean? The tool can run with root, or without it, in which case it uses Shizuku. The two modes have separate information documents and separate images in the repository, and the non-root path is the one with tighter limits on what can be written, so it is the one to read first when you are deciding. ### What is the kernel blocklist in FDE.AI-docs for? It records the kernel features the tool blocks. Since the engine configures the kernel and the operating system per device, some features will be disabled on some hardware, and the blocklist is the document that makes that auditable before you install it. ### How are FDE.AI updates delivered? Through the update manifest, a JSON file kept in the repository next to the release assets, so a device learns about a new version from the same place it downloads from. The version numbers are date based, with the year and month followed by a patch count, and the releases are tagged with the product name rather than the repository name. ## Sources - [feravolt/FDE.AI-docs on GitHub](https://github.com/feravolt/FDE.AI-docs) - [Issues](https://github.com/feravolt/FDE.AI-docs/issues) - [README](https://github.com/feravolt/FDE.AI-docs/blob/master/README.md) - [Releases](https://github.com/feravolt/FDE.AI-docs/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/feravolt-fde-ai-docs