App Manager | CHANNEL

What lies ahead? The future, as I see it, is very much uncertain. We are in a situation where things can go really bad at any moment. We can finally see a mutual agreement among the leaders of the world regarding mass surveillance (whatever they say out loud regarding privacy and security are just a sham), and I do not see anybody doing anything against this alliance. As Saruman put it, they [“are to remove only those who oppose” them. But as Captain Nemo has said, “There is hope for the future. When the world is ready for a new and better life, all this will someday come to pass, in God's good time.”

🎉 6 years of App Manager 🎉 Today marks the sixth anniversary of App Manager. Over the years, I have made significant effort to develop an app that offers some level of control over the digital life in the Android ecosystem. As of today, I wrote almost 250k lines of code (LOC) with over one million addition and removal in the version control system via 3,650 commits (that's 1.6 commit/day or 11.7 commits/week on average). I have closed almost 1,900 issues and handled over 2,000 private emails. We have over 200 translators translating App Manager in 39 languages. My efforts has largely been a success. Since I do not track users, and we do not have exact figures from F-Droid, I can only give you GitHub download statistics. From GitHub alone, App Manager has been downloaded over 681,170 times (the latest version alone was downloaded 225,321 times. It also reports over 13k biweekly unique active visitors and over 28k biweekly user engagement. This easily makes it one of the most engaging and active personal open source projects ever developed (which is also completely absent from the mainstream app stores). I stopped the fundraising campaign in 2024, almost two years ago due to personal reasons. In 2021-24, we hold four fundraising campaign each spanning three months and were able to secure almost $5,000, which was largely a success considering the amount of users at the time. App Manager project is not just an app, rather it is a front-end. It relies on at least five other projects for various features, such as Android Debloat List, Android Libraries, LibADB. Some of the projects have also helped other people in the long run. LibADB, in particular, has made adaptation of ADB-based features mainstream among the developers who build utility software alongside Shizuku (which is still non-free and as such many FLOSS lovers still ignore). App Manager is also one of the first material designed utility software on Android. In fact, one motivation for developing App Manager was the lack of well-designed software. Back then, there used to be a lot of utility software on F-Droid (most of them are now in F-Droid Archive), but none of them had modern design, because those applications were developed at a time when many developers actively rejected the Lollipop-era design and stuck with the pre-Lollipop design. Another issue was that the tools largely offered just one particular feature. So, we had to install several applications to achieve something that could've been just a single standalone tool. This was the second motivation. App Manager is developed for my personal use. If you are a software engineer or work in a tech company, you know how difficult it is to come up with a good design. This is partly because most of the people involved in the production never really use the product. So, they fail to think from the perspective of the user. App Manager is different. It's developed for my personal use, and I use various features several times everyday. So, I have a good understanding of the issues and how to solve them from an user's perspective. This is what made it so powerful. But be aware that App Manager is a very sophisticated and advanced utility software. It takes a lot of effort to keep it scalable, and unless you are a tech savy individual, you will probably never be able to appreciate its true depth. Although I wrote a 85 page documentation for App Manager (which is also very rare for a tool like this), it is very much incomplete.

Translators. If you've started translating App Manager as a new translator on or after 17 April 2025, make sure to request explicit permission as stated in the Weblate banner for the project. If you do not request permission, your translations will not be considered regardless of their quality. If you fail to do this by June 14, your past translations will be discarded. Note that asking for permissions does not ensure that your translations will be accepted. It will go through additional scrutiny to ensure that they adhere to our policies. You only need to request permissions once. If at any time we discover issues with your translations (such as machine or AI generated translations), we will take actions against you based on the type of violation.

📣 May'26 Updates It's been a while since I post the last update (which was September last year). As some of you are aware, I've been very busy with a lot of things and could hardly allocate time to my open source projects. However, I always try to respond to the emails and the issues raised on the GitHub issue tracker. There's a good news though. My course work for PhD will be completed at the first week of June, which means I no longer have to worry about attending classes and exams, etc., only research. This also means that I can finally allocate some time to my open source projects too. If you're translating App Manager, you may know that the translations have been locked for a while. This is because I am currently reviewing over 200+ translation contributions made in the last few months by over 50 translators. Once I am finished merging all the translations, I shall unlock the translations. The release process involves a few more steps though. First, I need to go through all the changes made (which is over one thousand). Then, I will update the documentation as well as write the changelog. Finally, I will do a final check to see if I have addressed all the issues that I have added to the milestone, and also if there are any security disclosures to be made (unfortunately, I cannot pay anybody for reporting security vulnerabilities though). Then the release will be made. The earliest possible date, as I have mentioned in the Matrix group a few months ago, is June (quite possibly in the third week). I am not going to work on any major features until the end of the year. So, the focus this year will be on improving the existing features, especially the permission management (like I mentioned in a previous update). As I mentioned before, the next release (v4.1.x) will be the last release to support Android Lollipop (5.0 and 5.1). After that the versions will diverge, and Android Lollipop users will only receive yearly updates. Google has also signaled that they are dropping support for Android Marshmallow (6.0) from the core libraries. If they do this by this year, it may extend to 6.0 too.

Good news! I have been successfully able to register App Manager and Captive Portal Controller in the Android developer verification console. From tomorrow, users from countries where App Manager had previously been restricted due to regulatory issues (e.g., Singapore, Thailand, Turkey) should be able to install App Manager without bypassing Google Play Protect. However, I didn't receive any updates from Google regarding how all these are going to play out with Google Play Integrity API. If you encounter any issues with you banking apps because of App Manager, please contact me with necessary documentation (Android version, affected app info, screenshots, etc.) so that I can discuss this with Google Play's support team. Note that due to the verification requirements, only the "official" version of App Manager has been registered. You can download the official version from the Telegram channel, GitHub releases, Matrix group, or IzzyOnDroid repository on F-Droid. There is another F-Droid version located in the F-Droid official repository which is signed by F-Droid and couldn't be registered at this moment.

I'm discontinuing support for debug builds altogether since the development has been significantly affected by my inability to allocate enough time to the project. The debug users are requested to migrate away from the debug builds as a result. Another bad news coming in the following year: Google has been removing support for SDK 21-22 (Android Lollipop) from the core libraries. This means App Manager will eventually have to discontinue support for Android Lollipop since it heavily relies on those libraries. (If you're still using Android Lollipop, it's probably to time to finally make that upgrade.) However, I plan to support the affected users as long as possible by offering a maintenance-only version of App Manager. This version will not be receiving any new features, but it will continue to receive critical bug fixes on a yearly basis. I'm still working on merging the translations from Weblate. After this is done, I need to update the docs and changelogs for the next release. Considering the amount of time I cannot allocate, I forecast that it will take one and half month more.

Notice. It appears the Debug channel was reported to Telegram by someone or some people, and Telegram decided that it violated their ToS without any explanation and thus blocked the channel. I have appealed against the decision, but unsure if they will restore it. If you cannot access the channel, you can always find the latest debug builds here: https://github.com/MuntashirAkon/AMInsecureDebugBuilds

Since Windows is unusable now (even Microsoft themselves admitted it), consider switching to Linux if not already. Here's a blog post I wrote about my experiences in switching to Fedora Workstation: https://blog.muntashir.dev/2025/12/18/fedora-workstation/

If any Linux users here, I've built a dictionary app for Linux (because it badly needed one): https://github.com/MuntashirAkon/SlobDict See my corresponding post for more info: https://infosec.exchange/@muntashir/115761100052449325 (Yes, I switched to Linux about a week ago, and this is the very first app I've ever developed for Linux.)

📣 Updated Website I've created a new personal website: https://muntashir.dev The GitHub site, muntashirakon.github.io is set to redirect to muntashir.dev. As a result, all the other GitHub pages also redirect to that website. Therefore, muntashirakon.github.io -> muntashir.dev muntashirakon.github.io/blog -> blog.muntashir.dev muntashirakon.github.io/AppManager -> muntashir.dev/AppManager (for now) muntashirakon.github.io/android-debloat-list -> adl.muntashir.dev (for easy access) PS: If you're interested in creating a domain maximizing privacy and security, I'd recommend porkbun.com. (No, they didn't sponsor me or anything, they're often recommended in privacy communities.)

Finally, for the APK updater, I've already created a backend for it. But there are still a lot of challenges, such as effective handling of extensions and errors, what to display to the user, implementing the update policies, and so on. This will take some time and probably available for testing at the first quarter of 2026.

📣 September'25 Updates This month (October) has been a busy month for me (I mean more than usual). I've had certain timeline set up for the next release, but due to my busy-ness, I don't think I will be able to meet my goals for the next release any time soon. Last time I've announced that I was working on ADB-based backups, and last month, I was able to integrate it fully into the existing backup model. This required a major rewrite of the backup/restore feature, but I think it would be beneficial to the large number of ADB users that App Manager has. Recently, somebody has created a feature request on GitHub regarding a ADB-based network firewall implementation. From Android 13, it is possible to utilize the Berkeley Packet Filter (BPF) to cut network connections from an application. You can also do this using ADB shell or terminal with root:

cmd connectivity set-package-networking-enabled [true|false] [package-name]

The underlying implementation fetches the UID of the package name and then add the UID and rule to a BPF map for filtering the packets for the UID (for shared applications, multiple applications packages may be blocked as they share the same UID). But the issue with BPF rules is that the rules do not persist across reboot. This means you'd need to reapply the rules after restarting your device which is inconvenient. A possible solution to the problem, of course, is reapplying the rules on reboot, which again, is not convenient since ADB mode is also lost after a reboot. So, to effectively implement this feature, we need to find a way to monitor Wi-Fi connections on reboot and connect to wireless debugging automatically once the device is connected to Wi-Fi. I've already implemented a prototype last night, and it's working correctly on my test device (Pixel 9). On Android TV, ADB over TCP persists across reboots, so we may also able to do something similar on Android TVs too. After the feature become stable enough, I think it would be possible to implement BPF-based firewall for devices that support it that would persist across reboots. IP tables based blocking and VPN-based packet filtering remain the most used filtering technology in Android due to the availability of many open source firewall tools (and closed source ones most of which are just clones of the former). However, these sort of blocking, as I've argued before, are not very effective, and from Android 12, their effectiveness has been further reduced. This has happened because Android 12 has integrated eBPF (extended BPF), and since then the internals of the AOSP has been modified to use eBPF instead of the traditional IP tables approach. If you don't know about BPF, let me explain it in simple words: BPF is a kernel-level packet filtering mechanism that has the ability to decide which packet (any data transmitted from or to the internet has to go through a few layers, packet is one of them) goes to where or which packets it needs to drop. This allows a system whitelisted program in Android to directly send/receive packets without going through the typical route used by ip tables or VPNs. This means that the vendor can arbitrarily allow their vendor (and system) apps to bypass ip tables and VPNs which is not good thing for user privacy since for these applications, all the protections (for example, anti-censorship protections) become useless. This is where the BPF rules may help. The underlying implementation of the above mentioned command modifies the BFP map albeit temporarily overriding the existing UID rules if already present. This effectively allows us to temporarily override the rules even for the whitelisted apps. But in some cases, the rules may be refreshed even without a reboot. I'm still currently investing the implementation, so I don't have the exact details.

I'll skip v4.0.6 and release v4.1.0 instead.

📣 August'25 Updates The next release of App Manager (that is, v4.0.5) is delayed because I was very busy with work last week. I try to release it in the next week as I need to take care of a few more things. At first, I'd like to talk about one of my concerns that has been in mind for a while. Despite what many politicians want you to believe, the world is in a grave financial crisis, and there is no easy way out of it. What we're seeing at present seems to be a replay of the financial crises in the 1970s, except the world is more connected than before, thanks to the Internet, and this has its own set of disadvantages like we saw during the Covid period when the world run into an absolute chaos. However, unlike Covid period, people's ability and motivation to continue hobbies are going to be challenged, especially if they are not financially productive, and this can have an adverse effect in the open source community where many projects (including App Manager and the related projects) are developed and maintained by hobbyists like me. Notice that App Manager costs me nothing other than time (which is still quite costly in the developed world), but there are many projects that are quite costly in terms of money and resources. Most concerning of all: some of them play a significant role in areas of utmost importance (like the Internet itself or defense, compared to App Manager which is not that important as a project) and are being developed by maintainers quite thanklessly without any form of compensation. This is going to be an acid test for the open source community, and I believe the landscape will see a significant alteration in the future. Of late, I've been working on the backup/restore feature of App Manager. As some of you, I've already created the framework for converting a App Manager backup to and from a regular ADB backup a long time ago, but handling ADB backup and restore itself is not that straightforward using the Android APIs, but it's not impossible, and since a lot of the users are now using App Manager in ADB mode, I think I'll give it one more shot. If I can implement this correctly, the feature will be available v4.1.0, otherwise we'll continue to test it in the debug versions. Lastly, I'm still looking for contributors for the ADL project. If you're interested, please send me an email with your Matrix username. Thanks.

Android Debloat List. I'm looking for a few contributors who can contribute to the ADL project on a regular basis for the vendor/oem of their choosing. Here are the requirements: 1. Must be able to contribute a few times per month 2. Must own a device from the vendor/oem 3. Must have a Matrix account (from any instance) 4. Expected to be able to use a text editor to edit JSON files 5. Expected to know how to navigate the GitHub website No other qualifications needed. I'll be responsible for mentoring the contributors through a Matrix group as well as GitHub. Initially, we shall start with all the interested individuals and gradually eliminate those who fail to maintain the requirements. Interested individuals are requested to send an email to am4android@riseup.net with GitHub and Matrix usernames with the subject line prefixed "ADL".

To clarify the level of trust a bit more, it's necessary to support only the legitimate sources instead of arbitrary source and assign each a priority which are actually more challenging than the rests, because the definition of legitimate sources remains unclear to me, and without an exact definition, it's almost impossible to assign priorities as well. I initially came up with a priority list for the app stores, but I didn't explain why they were prioritized this way. Therefore, it is necessary to define leigitimate sources and factors that are needed to be taken into account to assign priorities. Again, this is a challenging problem, and for now, I'll rely on my own instinct for it. For the same reason, App Manager will not support any third-party updater extensions. The updater will rely on a signature permission to interact with the sources, and therefore, the extensions must be signed using the same key used to sign App Manager.

📣 July'25 Updates

In order to provide a convenient option for non-Telegram users to follow the updates, they will also be posted on my personal blog. Past updates will also be gradually added there. You can subscribe to my blog posts via RSS or follow my personal Mastodon/X account. Transparency reports will also be posted to App Manager's official Mastodon/X accounts. An archive of the reports will be maintained in a GitHub gist for now.

I think many testers already knows this: I've implemented a new type of profile that allows filtering apps by the set of filters offered by the Finder feature. This feature is going to be very useful for recurrent activities like force-stopping all the user apps that are currently running. Again, the possibilities are endless. Although the regular apps-based profile is kind of a subset of this profile, I decided to implement them separately to keep the apps-based profile very simple and fast to execute (since filter-based profiles are inherently slower than apps-based profile). The feature will be available to stable users from v4.1.0 (release date not fixed yet). The filters in the main page are also being migrated to use the Finder-style filters so that the users can generate and use their own set of filters instead of the predefined ones. Finder itself along with this exclusive filtering options will be available to stable users in a future release. I have done some progress on the updater implementation and can share some of the ideas to the readers for both transparency and scrutiny. But at first, let's take a look at the issues that we need to handle in order to implement a unified updater: 1. App Manager app itself has limited internet features, and we intend to keep it this way 2. It's necessary to enforce a static single source assignment, that is, once an installed app is assigned to a source, subsequent updates should also be sourced from that source 3. It's also necessary to establish the levels of trust and the priority of sources should be assigned based on the trust 4. It's crucial that the users can amend 2-3 depending on their threat model. These are very challenging issues, and addressing them completely is nearly impossible. But I've designed a protocol and a framework to address those issues in an optimal way. In this protocol, App Manager effectively acts an updater client that retrieves updates from the sources which are basically extensions to App Manager. The update process itself works in two independent steps. In the first step, App Manager queries the sources for new updates (based on the source assignment). Upon receiving such a query, the sources check for updates and return a list of updates to App Manager. In the second step, App Manager ask the sources to download some (or all) of those updates which the sources download (or retrieve from caches) and return a list of URIs that App Manager has access to. App Manager later retrieves those updates and installs them. This design has several advantages: 1. Each source remains separate and can be installed or removed independently 2. For each source, it's possible to assign a trust level and handle per source security (HPKP, GPG, etc.) 3. Each source only uses the minimum number of permissions to function which reduces the attack surface even if some of the security mechanisms are bypassed 4. It's easy to provide per extension updates compared to the monolithic approach where any simple changes to any sources requires a new update 5. Using modern Android platform features, it's easy to persist single source assignments beyond App Manager.

BTW, those who are interested in understanding the permissions used by App Manager, you can navigate to the Permissions section in the link above.

Now also available on IzzyOnDroid: https://apt.izzysoft.de/fdroid/index/apk/io.github.muntashirakon.AppManager