SetEdit
The settings database editor for Android

F-Droid: https://f-droid.org/packages/io.github.muntashirakon.setedit

The open source version of Settings Database Editor by 4A.

WARNING -- I do not guarantee that problems caused by the improper use of this utility can be fixed, and we are unable to help you with any such problems. We support only this app, not your device's system software. Settings Database Editor (SetEdit) is invaluable if you need it, but if you're not careful you're very likely to mess something up.

By default, for your protection, Android prevents you from modifying the SECURE and GLOBAL tables. If you have Android Jellybean or later, you can remove this protection from an ADB shell using the command pm grant io.github.muntashirakon.setedit android.permission.WRITE_SECURE_SETTINGS. On earlier versions, you can only remove this protection on a rooted device by installing SetEdit to the system partition.

Both WRITE_SETTINGS and WRITE_SECURE_SETTINGS permissions are optional if you do not need to edit any items.

APKM finally went DRM-free! If you’ve downloaded the latest version of an app in APKM format, just rename it to APKS and open it via AM (or using your favourite app).

UnAPKM v1.3

Do not attempt to convert DRM-free APKM files. If you get the DRM-free message, just rename the APK file to APKS and open it with your favourite APKS installer.

AppManager v2.5.22 Pre-release

- 1-Click Ops: add backup/restore options
- Added encryption info in about device
- Added the ability to freeze backup (by creating .freeze in the corresponding backup)
- Added option to enable/disable MagiskHide in the App Info tab (enable option in the overflow menu)
- Added option to enable/disable interceptor (in settings)
- Added option to launch services
- Added option to select backup volume
- Backup/restore app installer, netpolicy, deviceidle, magiskhide and notification access
- Backup/restore URI grants (need immediate reboot after the restore)
- Block and disable components using IFW and PackageManager respectively for maximum protection
- Grant/revoke permissions in profile
- Improved instructions in the 1-Click Ops page
- Integrated docs within AM as a dynamic feature
- New attribute in backup/restore: size
- New attribute in profile: users
- New tag in App Info: backups
- Open DRM-free APKM files without conversion
- Sort apps by labels, display user/system tag in the profile page
- Replace backup all users with custom users
- Updated trackers and libraries
- Remove FLAG_ACTIVITY_FORWARD_RESULT from list of flags (if present) in the interceptor
- Add .nomedia file in the backup folder
- Fixed crash on clicking the about device item in Settings
- Fixed crash in the profile page
- Fixed compatibility issue of IFW in Android M or prior versions
- Get correct user ID before performing uninstall
- Migrate to PackageManager API instead of using unreliable pm command
- Update theme name on changing app theme
- Use package name from metadata instead of directory name for backups

Backup/restore feature is now in beta. From now on, backward compatibility for backup/restore will be provided.

Since newer APKM files are no longer encrypted (consequently, they don’t need decryption), it was decided that unAPKM would be separated from the main app as an extension after three months, preferably at the end of April.

Dear debug build users,
If you’re getting random crashes or weird behaviours that you suspect should not happen, try reinstalling the app. If this doesn’t work, then uninstall, restart and then install the app again. If these two methods do not work, then and only then report to me. Debug builds are intended for testing purposes only and they might misbehave as they contain debug symbols.
Thanks.
@MuntashirAkon

AppManager v2.5.23 Pre-release

- [Feature] Added screen lock
- [Feature] Added Add to profile in the batch ops and app info tab
- [Feature] Added enable/disable features in settings (replacing interceptor setting)
- [Feature] Added leanback launcher support with banner (Android TV)
- [Feature] Backup/restore SSAID (requires immediate restart)
- [Feature] Backup APK in external SD card
- [Feature] AppInfo: Added options to configure battery optimization, net policy, SSAID. For each of them, tag clouds will be displayed if the values are not default.
- [Feature] AppInfo: Added options to select tracker components to block/unblock
- [Feature] Improved backup volume selection
- [Feature] Interceptor: add/remove extras
- [Feature] Made settings page accessible from Android Settings
- [Feature] Main: Added filter by installed app, sort by number of trackers and last actions (the latter is not stable yet)
- [Feature] Main: Batch selection on long click after the selection mode is turned on (i.e. selection mode is turned on if you click on any app icon or long click on any app)
- [Feature] Main: Replaced sort and filter with list options
- [Feature] Main: Set backup to red if the app is not installed
- [Feature] New language: Japanese
- [Feature] Removed F-Droid, Aurora Droid in favour of F-Droid links (to support user preferred clients)
- [Feature] Search using app initials in the main page (e.g. TS will list TrebleShot in the search results)
- [Feature] Updated trackers, libraries, profile presets
- [Feature] Use of database as a middle man to improve load time
- [Fix] Fixed app icon (it now matches app theme)
- [Fix] Fixed crash while blocking app components of a recently updated app
- [Fix] Fixed various crashes in the app info tab
- [Fix] Properly sanitize profile names and exported APK(S) file names
- [Fix] Remove rules for all users (rather than the current user) in settings
- [Fix] Replaced AppManager/tmp with AppManager/.tmp
- [Fix] Replaced image buttons with material buttons (fixes crash when using Substratum themes)

Don't set folders inside /mnt/media_rw/ as the backup volume. It doesn't work for backup/restore.

Sneak-peek: My attempt to redesign Android Terminal Emulator, the best terminal ever created for Android.

Source code: https://github.com/MuntashirAkon/termoneplus

Dependencies of Firebase Android SDKs on Google Play services

Some Firebase Android SDKs depend on Google Play services, which means they will only run on devices and emulators with Google Play services installed. These Firebase SDKs communicate with the Google Play services background service on the device to provide a secure, up-to-date, and lightweight API to your app. Certain Android devices, such as Amazon Kindle Fire devices or those sold in some regions, do not have Google Play services installed.

HINT: Most of the Firebase SDKs do not require Google Play services with the exception of FCM, AdMob, App Indexing and ML related stuffs.

https://firebase.google.com/docs/android/android-play-services

What are bloatware and how to remove them?

Bloatware are the unnecessary apps supplied by the vendors/OEMs and are usually the system apps. These apps are often used to track users and collect user data which they might sell for profits. System apps often do not need to request any permission in order to access device info, contacts and messaging data, and other usage info such as your phone usage habits and everything you store on your shared storage(s) as they are already granted/whitelisted by the vendors/OEMs.

The bloatware may also include Google apps (such as Google Play Services, Google Play Store, Gmail, Google, Messages, Dialer, Contacts), Facebook apps (the Facebook app consists of four or five apps), Facebook Messenger, Instagram, Twitter and many other apps which can also track users and/or collect user data without consent given that they all are system apps. You can disable a few permissions from the Android settings but be aware that Android settings hides almost every permission any security specialist would call potentially dangerous.

If the bloatware were user apps, you could easily uninstall them either from Android settings or AM. Uninstalling system apps is not possible without root permission. You can also uninstall system apps using ADB, but it may not work for all apps. AM can uninstall system apps with root or ADB (the latter with certain limitations, of course), but these methods cannot remove the system apps completely as they are located in the system partition which is a read-only partition. If you have root, you can remount this partition to manually purge these apps but this will break Over the Air (OTA) updates since data in the system partition have been modified. There are two kind of updates, delta (small-size, consisting of only the changes between two versions) and full updates. You can still apply full updates in some cases, but the bloatware will be installed again, and consequently, you have to delete them all over again. Besides, not all vendors provide full updates.

Another solution is to disable these apps either from Android settings (no-root) or AM, but certain services can still run in the background as they can be started by other system apps using Inter-process Communication (IPC). One possible solution is to disable all bloatware until the service has finally stopped (after a restart). However, due to heavy modifications of the Android frameworks by the vendors, removing or disabling certain bloatware may cause the System UI to crash or even cause bootloop, thus, (soft) bricking your device. You may search the web or consult the fellow users to find out more about how to debloat your device.

From v2.5.19, AM has a new feature called profiles. The profiles page has an option to create new profiles from one of the presets. The presets consist of debloating profiles which can be used as a starting point to monitor, disable, and remove the bloatware from a proprietary Android operating system.

Note: In most cases, you cannot completely debloat your device. Therefore, it is recommended that you use a custom ROM free of bloatware such as Graphene OS, Lineage OS or their derivatives.

Note 2: In future, AM will add systemless removal of the system apps which can prevent communication using IPC.

https://muntashirakon.github.io/AppManager/faq/misc.html#what-are-bloatware-and-how-to-remove-them

More on the INTERNET permission.

After I’ve explained the reasons for AM to use the INTERNET permission, some of you have asked if there are any privacy benefits in blocking an app’s Internet connection via Firewall. The answer is: Maybe.

If an app has declared the INTERNET permission, the app can make socket connection. Socket connection can be opened in any port and can connect to any IP address (both local/private and the Internet). For some weird reasons, Android doesn’t differentiate between private and public IP addresses which means if a developer want to use socket (others include Binder and Message) to communicate between two apps or processes i.e. with no intention of connecting to the Internet, they must declare this permission.

Communication between two apps or processes is called Inter-process communication or IPC in short. Android uses SELinux and separate user ID (UID) and group ID (GID) to ensure that each non-shared (shared processes can communicate freely) process cannot communicate among each other directly. However, they can still communicate using methods such as (Web) Socket, Binder and Message. As I said earlier, Socket needs a port and an IP address (for IPC, IP address could be 0.0.0.0 and port number can be anything that is allowed and free-to-use at that time). However, Binder and Message do not require any IP address or port number. An example of this is the clipboard. When you copy some texts, say, in Bromite, it uses Binder to communicate to the ClipboardManager which is a service defined in AOSP, and then it uses the service to store the texts in the clipboard. The similar is possible for a service (actually any service that uses Binder) called DownloadManager. If the app requests an webpage or a file using the DownloadManager service, it connects to the caller app via Binder and checks if the caller has the INTERNET permission. If it has, then it initiates the download and sends the result. Otherwise, it simply fails. So, if you enable Internet firewall of the caller app, then the app itself cannot connect to the Internet. But it can still connect to the Internet using DownloadManager since you haven’t blocked the Internet connection for DownloadManager. What if you block Internet connection for the DownloadManager? If you do that, then all apps that rely on DownloadManager will not be able to connect to the Internet and anything you download from a browser such as Bromite will simply fail. The solution, here, is to edit out the INTERNET permission from the APK file itself (or use GrapheneOS which can revoke this permission effectively). However, this isn’t the end of the irony. The app can also utilise other apps with unpatched vulnerabilities to make the same connection (either via Binder or calling an infected service via Intent). In the latter case, editing out the INTERNET permission may not help at all (and GrapheneOS may not be able to block that either).

Got an app that uses root but has no INTERNET permission? Don’t get excited. The app can access and send all your data without any permission! How? Android can only check the permission of the immediate caller. So, if the app creates a root process and connects to the Internet from there (the app in turn communicates to the root process via Binder), Android would allow that since the caller is a root process and not the app. So, never trust an unaudited app, specially, the closed source ones.

To conclude, determine your threat model. If you only need to protect yourself from the evil corporations or to improve privacy, use DNS or hosts based blocking because they are more effective than the firewalls. If you need to block the Internet connection from certain apps only, first check if firewall works for it (in my experience, NetGuard works better than AFWall+) and if not, use an APK editor to remove the INTERNET permission from the AndroidManifest file and install it.

This is a detailed explanation of @madaidan’s guide on Firewalls which can be found here: https://madaidans-insecurities.github.io/android.html#firewalls

Web: https://muntashirakon.github.io/AppManager/en/

Comments are welcome.

Release Types, Schedules and Sources

App Manager has several types of releases based on user requirements and stability.

1. Stable release. Stable releases like any good software are very infrequent and long term supported. In future, when we finally reach v2.6, we will follow the major.minor.patch version naming instead of 2.major.minor and provide special fixes for stable releases so that users can continue to use stable releases without switching to pre-release. (Non-linear versioning is difficult to handle but we will do that anyway to improve experience for the stable release users.) Stable releases are available on GitHub, F-Droid (may lag behind updates) or Telegram channel.

2. Pre-release. Pre-releases are the unstable releases that are usually made when the number of commits has reached or surpassed 100 (with the exception of the source code being too unstable). Prereleases are discontinued. Use debug releases instead.

3. Debug release. Debug releases are usually served on each push to the repository. This is for the people who want to try out features as they are rolled out and want to contribute to App Manager by sorting out issues. Debug builds use a different package name and a signature, and can be installed side by side with the normal releases. Signature used in debug builds is public and, therefore, they should only be installed from a trusted source such as GitHub actions and Telegram channel.

Unofficial sources may distribute modified versions of App Manager, and none but you shall be responsible for the consequences of using such distributions.

App Manager v2.5.24 Pre-release

- [Feature] New language: Tradition Chinese
- [Feature] Added filter by uninstalled apps, apps without backups in the main page
- [Feature] Added wildcard support for app ops and permissions for profiles. * can be used instead of specifying app ops or permissions to revoke all configured/dangerous permissions/app ops
- [Feature] Allow specifying custom installer package which may or may not be installed
- [Feature] App icons are cached to improve load time
- [Feature] Complete rewrite of running apps internals in Java
- [Feature] Copy package name on clicking on the package name in the app info tab
- [Feature] Display file size, requirement, etc. for split APKs in the APK selection dialog
- [Feature] Display version and tracker info in the install confirmation dialog
- [Feature] Display uninstalled system apps and display installation prompt on clicking them
- [Feature] Improved ADB detection and persistence of such detection
- [Feature] Removed toybox along with its dependencies
- [Feature] Updated trackers and libraries
- [Feature] Updated credits
- [Feature] Utilise multiple CPUs for back up/restore
- [Feature] Verify copied checksum with the checksum of the signing certificate of the app on clicking on the app icon in the app info page
- [Fix] Added additional verifications to ensure that screen lock is not bypassed
- [Fix] Fixed back up/restore failure on some Android devices
- [Fix] Fixed crashes in the app details page when system configuration changes
- [Fix] Fixed crash on creating shortcuts on devices that do not support pin shortcut
- [Fix] Fixed generating wrong checksum for certificates in the signatures tab
- [Fix] Fixed uninstalling app for multiple users
- [Fix] Fixed various crashes on opening APK files from external apps
- [Fix] Hide backup option if one of the selected apps is not installed
- [Fix] Verify KeyStore backups during restoring a backup

We're now hitting a major release (v2.6.0). This is going to be the first long term supported release, i.e. this will be the first version of app manager to receive patches until the next stable release is made.

App Manager is something I made for myself and never really thought that it would reach so much audiences. Now, I can feel that there are many people like me who were waiting for an app that would help them replace privacy invading, non-free apps as well as help those who're suffering from the guilt of using cracked software. The development of App Manager was so fast because I've spent a lot of time analysing other not-so-usable and, often abandoned projects which has given me insights on how to implement such features. I'm also working very hard to ensure security of the data because a rooting app itself is never fully secured (and you're welcome to find any security issues!).

Therefore, it's time to change the name of the app to something special so that it can be uniquely identified (the package name will still be the same though and the old repository will be redirected to the new one).

The best name will be chosen based on the apps functions and/or creativity, and the person will be credited in the about section!

Post your ideas here: https://github.com/MuntashirAkon/AppManager/issues/339