Open-source project
Xposed-Modules-Repo/com.tsng.hidemyapplist avatar
Xposed-Modules-Repo/com.tsng.hidemyapplist

Hide My Applist hides your installed apps, and tells you when it fails

隐藏应用列表 / Hide My Applist

704 stars19 forksUnknownLicense varies

At a glance

What is it?
Hide My Applist is an Xposed module for Android that either hides installed apps from other apps or rejects their app list requests, and this repository is a mirror entry point rather than the module source. The documentation also frames detection as a privacy failure, since apps that read your installed apps can profile the tools you use.
Who is it for?
Hide My Applist suits an Android user on a rooted or Xposed system who wants to stop apps from reading the installed package list, and it does not suit someone who needs a guarantee of invisibility, because the documentation itself notes that apps using loopholes to obtain the list are a separate case.
Can I use it commercially?
Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
Is it still maintained?
Yes. The repository last received commits 83 days ago.
What is it written in?
GitHub does not report a main language for this repository.

Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.

Editorial analysis

This repository is a mirror pointer, not the module source

The most important fact about this repository is visible in its contents. The top level holds three files: README.md, a SOURCE_URL file and a SUMMARY file. There is no source tree, no build configuration and no manifest, and the project metadata records the primary language as unknown and the licence as unknown as well, which is exactly what you would expect of a repository that carries documentation rather than code.

The README points at the source address, and the project homepage is the upstream repository for the module. The release badges in the README also point upstream, at the releases page of the source repository, as does the download badge and the Telegram channel link.

So the useful question about this copy is not what it contains but what it tells you. It is an index entry in a modules collection, and its job is to describe the module, carry the licence badge, and point at the place where the code and the downloads live. Any decision to build, install or fork the module has to be made against that upstream repository, not against this one.

The problem: apps read your installed apps and profile you

The module's own description of the problem is unusually concrete, and it is worth reading carefully because the module does more than block a permission.

The documentation notes that some apps use various loopholes to acquire the installed app list, bypassing the system permission, and that they do this in order to draw a persona for you. The example given is dividing users who have V2Ray installed into a category of their own, and a second example is software that requires you to uninstall cheating tools before it will let you use it. The consequence in both cases is that the app knows something about your device that you never chose to disclose, and uses it to shape how it treats you.

That framing is the reason this is a privacy module rather than a detection tool. A person who runs a particular tool, a particular app or a particular modification, and who is grouped by that fact, is a person whose device configuration is being read as an identity. The module's response is to remove that input.

It is worth saying that the documentation does not treat app detection as a reasonable practice in the first place. The README calls it incorrect and, in the Chinese version of the same note, says bluntly that it is also foolish. The module is not trying to make detection harder for honest apps. It is trying to take the signal away.

Why hiding a root app is close to hiding root itself

The module offers a specific test for checking whether you have hidden a given package name, with Magisk and the Edxposed Manager named as the examples, and it also works as an Xposed module that hides some apps or rejects app list requests outright.

The subtle part is the argument the documentation makes about what a successful hiding means. It observes that not every app that uses root provides random package name support, and it reasons from there that an app detecting a root-dependent app such as a fake location tool or a storage isolation tool is, for practical purposes, detecting root itself. A random package name changes what the app list looks like to everyone, so an app that still recognises a well-known root tool by name is not fooled by the renaming trick.

This is the difference between two strategies for the same goal, and it is the clearest alternative available to you. The first is the app's own random package name support, which pushes the responsibility onto every app that reads the list. The second is a system level hook, which intercepts the list at the point of request and can hide or reject selectively. The module is the second strategy, and it also supplies the means to check the first one, since a package name that a detection test can still find has not been hidden in any meaningful sense.

A dual purpose module: a diagnostic and a hook

Most tools in this category do one of two things. They either hook the system and hide things, or they report on what a given app can see. This module does both, and the README describes them in the same breath.

The detection side provides methods to test whether you have already hidden your app list well, meaning the module can show you, from the outside, what another app would find in your installed applications. The hook side makes it possible to hide specific apps or to reject app list requests outright, which is the privacy function.

The combination is the reason to keep both in one project. A hook without a test tells you nothing about whether it worked, and a test without a hook only tells you that you are exposed. Used together, the test tells you which package names are still visible, and the hook decides what should be visible.

The documentation is candid about the limits of the diagnostic. Because apps that read the list through loopholes are a different case from apps that respect the permission, the test is best understood as covering the path the module can actually intercept, rather than as a guarantee of invisibility to every application on the device.

Release tags carry two version numbers and a commit

The release history shows a naming scheme that packs more than one number into each tag. The most recent is 520-3.8.3.r520.9605640 for version 3.8.3, published on 2026-08-01, and before it sit 499-3.8.r499.3a346c0 for version 3.8 on 2026-05-13 and 462-3.6.1.r462.4524dde for version 3.6.1 on 2025-10-18.

Read as a structure, each tag has a leading number, the module version, a matching internal number prefixed with r, and a short commit hash. The module version alone therefore does not identify a build, and two different tags can carry the same application version with different underlying code. For anyone pinning a build, that distinction matters, and the hash at the end is the part that pins the code exactly.

The last push to the master branch of this repository was on 2026-08-01, the same day as the 3.8.3 release, which is consistent with a mirror that is refreshed when upstream publishes. Between the 3.6.1 tag in October 2025 and 3.8.3 in August 2026 there is a gap of several months with no tag, so the release cadence is not a fixed schedule. The README also carries a Telegram channel badge, which is where a user would look for announcement of new builds.

The licence badge is a claim this copy cannot back up

The README carries a licence badge pointing at the GNU General Public License version 3.0 page on choosealicense.com, which is the conventional way to display a licence on a project README. In this repository there is no licence file, and the project metadata records the licence as unknown, since the only files present are the README, the source URL and the summary.

This is a normal artefact of a mirror rather than a sign of a problem with the upstream project, but it has a practical effect: if you are deciding whether to use, modify or redistribute the module, you need to open the source repository and read the licence and the notice files there. The badge in the README points at a licence page, not at the text of the licence as it applies to this build.

The same reasoning applies to the code itself. There is nothing here to audit, no manifest to inspect and no changelog beyond the release tags in the upstream repository. Judging the module means reading the source, not this entry.

Editorial conclusion

Hide My Applist suits an Android user on a rooted or Xposed system who wants to stop apps from reading the installed package list, and it does not suit someone who needs a guarantee of invisibility, because the documentation itself notes that apps using loopholes to obtain the list are a separate case. Before installing, read the source link in this repository rather than building from it, check that your app list is actually hidden with the module's own detection methods, and confirm the licence in the source repository, since the GPL badge here is not backed by a licence file in this copy.

Frequently asked questions

What does Hide My Applist do?

It provides methods to test whether you have hidden your installed app list, with package names such as Magisk and the Edxposed Manager given as examples, and it can work as an Xposed module that hides some apps or rejects app list requests in order to protect privacy.

Does this repository contain the Hide My Applist source code?

No. The top level of this repository holds only README.md, SOURCE_URL and SUMMARY, and the README points to the source address and to the releases of the upstream project. The project metadata lists the primary language and the licence as unknown for the same reason.

Why is hiding a root app similar to hiding root itself?

The documentation argues that not every app that uses root provides random package name support, so an app that recognises a root-dependent tool such as a fake location or storage isolation app is effectively detecting root. A renamed package only hides the app list from applications that look at the names alone.

Official sources

  1. Issues
  2. Project website
  3. README
  4. Releases
  5. Xposed-Modules-Repo/com.tsng.hidemyapplist on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/xposed-modules-repo-com-tsng-hidemyapplist.svg)](https://hysenlabs.com/projects/xposed-modules-repo-com-tsng-hidemyapplist)

Was this useful?