📣 May'25 Updates

It's been five years since I've started developing App Manager, and it's been an interesting experience. I've been part of a lot of communities before this, but Android community is probably the most diverse community so far. In Hackintosh community, for example, most people were highly technical, because you needed to know a lot about the hardware in order to build a hackintosh. It was particularly challenging for laptops since most of the hardware (e.g., PCI(e) devices) cannot be replaced unlike, say a desktop. With the introduction of Clover, and then OpenCore, the complexity has been greatly reduced, but it's still challenging to work with a laptop, especially with the newer graphics cards which aren't even support by the recent version of macOS (but some people are trying to find workaround). Anyway, the amount of dedication displayed by the hackintosh community is really impressive, and it's also a showcase of how resilient software engineers can be when they encounter challenges. Then there was also the Croissant project (which has been renamed to something else that I have forgotten about) where I have made some initial contributions, but Chrome OS itself is a dead end, and Google knows it very well. The experiences I've gathered from these two communities, in particular, have largely enhanced my ability to sustain an open source project. My inspiration for documentation, for example, is the OpenCore project.

App Manager v4.0.3 had a terrible bug that caused App Manager to crash or freeze (depending on device/OS) if certain keywords are used during searching/filtering. The issue has been addressed in v4.0.4. Interestingly, this has resulted in the creation of 29 duplicate issues (so far). This demonstrates how important it is to look for similar issues before opening a new issue, or GitHub suggesting similar issue based on the noscript or issue content while the user is creating a new issue (similar to what we already have in many other websites). GitHub also has a terrible search option that tends to ignore older issues.

Shizuku has recently altered its license terms to make the project completely open source (as opposed to source available that it previously was). I absolutely welcome this change and thank vvb2060 for making this change. Some of you may now ask whether I've got any plan on supporting Shizuku. Let me explain this a bit.

Since v4.0.0, much of the compatibility layers in App Manager have been rewritten to allow a certain level of flexibility in terms of the mode of operations. From v4.0.1, it is also possible to alter the mode of operation to any UID of your choice provided they support reading and executing the start command. It is even possible albeit with certain modifications to run App Manager as a system app with permission whitelists or as a system level UID (latter is too risky). So, in a way, it is now possible to add Shizuku support in App Manager. At this point, I may need to spend some time with their API to understand how it works. My expectation would be a generic API (similar to Open KeyChain's) that would allow connecting to any Shizuku-style applications, including any future Shizuku forks (since it is open source now) instead of Shizuku "official" app alone.

Lastly, Eid Mubarak to those who celebrate Eid-ul Adha.

Privacy Digest: June 2025.

Time Interval: July 2024 - December 2024
Total communications: 242
Total active communications: 93 (149 communications were deleted)

In order to improve community transparency, I'm also publishing blacklists present on GitHub and Weblate:
1. GitHub: https://gist.github.com/MuntashirAkon/60f3988a23e90f767edb2f747febf567
2. Weblate: https://gist.github.com/MuntashirAkon/e4288f015898a152ffa4479e7e8985c0

The gists above will be periodically updated with the latest changes.

PS: As always, any inquiries regarding App Manager sent to any other email addresses other than the official email address were discarded regardless of the contents.

📣 June'25 Updates

There hasn't been a release last month because there were no significant changes to the project that requires a new release. Last month, I along with IzzySoft have tried to make App Manager reproducible and has largely been successful. All the debug releases are now reproducible, and the stable releases too shall be reproducible from the next release (v4.0.5).

The highly anticipated "Finder" feature is nearing completion, and I think, I can launch it at the end of this month or the next. This feature required some thorough planning in order to make it future-proof and usable for most users (and much more usable for advanced users). Initially, only a handful of features will be enabled for the stable releases, and gradually all the anticipated features will be released. The reason for this kind of rolling release is because we no longer have the beta testing system that we used to have, yet a certain level of confidence is required in order to release a feature like this. Similar to profiles, the possibilities with this feature is endless, some of which may remain unknown for some time. There are also a few small but exciting improvements that are coming up (which shall be revealed in due time) in the upcoming releases.

Regarding the app store functionality, I've given it a thought and concluded that rolling out an entire app store is time consuming and largely unnecessary for the time being. Instead, we can launch an update functionality instead. The update functionality, unlike F-Droid or Obtainium, will adhere to the Android principles at the same time offering a level of privacy and security that will be suitable for a wide range of individuals (as always, in developing App Manager, I've always focused on offering a diversified threat model so that it can accommodate most users). You can find some information regarding the design at this link: https://github.com/MuntashirAkon/AppManager/issues/464. However, there are a few changes to the original design which will be revealed as I begin working on it.

That's all. Thanks for reading.

#stable #release
App Manager v4.0.5

- App Manager releases are now reproducible!
- AM Debug builds are also available at https://github.com/MuntashirAkon/AMInsecureDebugBuilds

1-Click ops
- Enabled "Clear data from uninstalled apps" to no-root users
The option was altered to uninstall the apps a second time instead of attempting to clear data which was faulty. Therefore, it should work with any modes of operation.

App info
- Open "Open by default" setting in the "Open links" dialog
If App Manager does not have enough permission to manage domains or links, the "Open links" dialog has a button that directs the user to Android Settings. If the application has the "Open by default" page, clicking on the button will open that page instead of the "App info" page (which is still used as a fallback method).
- Fixed freezing an app with "Remember for this app" turned on.

App ops
- Fixed setting app ops in custom ROMs with MIUI properties injected.

Debloater
- Display unsafe bloatware info
- Sort by app label (or app name) rather than package name.

Installer
- Added option to allow installing the existing applications
Existing application is one whose APK files are still available in the system, either because it's a system application or an user application installed for another user. It can be installed for the current user by providing a URI to the installer that has the following format:

package:package-name

App Manager inherently does not check for permissions when such requests are directly made to its installer. Therefore, it will attempt to install the requested package directly and fail if there are not enough permissions.
Install requests are also allowed to be mixed together. Therefore, a third-party application can combine different URIs (e.g., file, content, package) with the SEND_MULTIPLE action.

Log viewer
- Activated "Omit sensitive info" option by default for new users.

Profile
- Fixed updating profile modification status when an application is deleted from the list.

Terminal
- Handled common colors and cursor movements.

Others
- Display vector icon on the splash screen in Android 7.1 and earlier
- Enabled predictive back in Android 14 onwards
- Improved accessibility by updating the content denoscription of the action items
- Fixed selecting texts in the list items due to framework bugs.

Full Changelog: https://github.com/MuntashirAkon/AppManager/compare/v4.0.4...v4.0.5

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

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

📣 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 know 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 as 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.

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.

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".

There is no deadline, and you can apply any time.

UnApkm v1.4

Updated dependencies and now targets Android 15.

Although APKM files are no longer encrypted, the App Manager plugin is still being updated to support decrypting the legacy APKM files.

📣 August'25 Updates

The next release of App Manager (that is, v4.0.6) is delayed because I was very busy with work last week. I'll 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 ran into an absolute chaos. However, unlike the 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 know, 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.

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

📣 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.

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.

📣 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.)

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.)

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/