How to Extract App Package Names from Standalone Uninstalled APKs in Tasker

 

So I was messing around with Tasker recently, trying to build a profile that reads the package name straight off an APK file sitting in my Downloads folder, and I honestly hit a wall pretty fast. I searched everywhere trying to find a straightforward way to pull an app's package name from a standalone APK, but came up empty every single time. I could easily grab the APK's file name into a variable, sure, but the actual package name? Nowhere to be found using the normal built-in stuff.

Turns out, the reason for this is pretty simple once you understand it: Tasker's built-in App Info action only works on apps that are already installed on your device. It reads package info straight from the system's installed app registry, so if your APK is just sitting there as a raw file, uninstalled, Tasker has genuinely no built-in way to peek inside it and tell you what package name it belongs to.

But don't worry, there's a workaround, and it actually works really well once it's set up. Let me walk you through exactly how I got this working using Android's PackageManager through Tasker's Java Functions plugin.

Overview and Use Case

The core issue here is that Tasker's normal App Info action depends entirely on the app being installed already. It simply can't reach into a raw APK file sitting in storage and extract metadata from it, because as far as Android's concerned, that file isn't "an app" yet; it's just a static archive.

The fix is to bypass Tasker's built-in action entirely and go straight to Android's PackageManager class using Java Functions. PackageManager has a method specifically built for parsing static APK files without needing them installed first, which is exactly what we need here. Once you're pulling data through PackageManager directly, you can extract the package name, version info, app label, and even the icon, all without ever installing the APK onto your device.

Prerequisites and Tasker Setup

Before diving into the actual logic, there are a couple of things you need sorted first.

You'll need storage access permission granted to Tasker, since we're reading an external APK file directly off your device's storage. Without this permission, Tasker simply won't be able to access the file path you're pointing it to.

You'll also want a variable ready to hold your file path, something like %apk_path, which should contain the absolute path to your .apk file. For example, mine looked something like /sdcard/Download/app.apk. Just make sure this path is accurate, and the file actually exists there; otherwise none of the following steps are gonna work.

Step-by-Step Tasker Logic

Alright, here's the actual meat of the setup, broken down action by action.

A1: Set Your Target File Path

First thing, store your APK's file path inside a local variable. This is as simple as setting something like %apk_path to /sdcard/Download/app.apk, or wherever your actual APK happens to be sitting. Just double-check the path is exact, since even a small typo here will break everything downstream.

A2: Fetch the PackageManager

Next, using a Java Function action, call CONTEXT.getPackageManager(). This grabs a reference to Android's PackageManager system service, which is basically the tool responsible for reading and managing all package-related data on your device, whether an app's installed or not.

A3: Parse the APK Archive

Now here's the key step that makes this whole thing possible. Call pm.getPackageArchiveInfo(%apk_path, 0). This method is specifically designed to parse a static APK archive file and generate a PackageInfo object from it, without requiring the app to actually be installed. This is genuinely the piece that Tasker's built-in action is missing, and it's the whole reason this workaround exists in the first place.

A4 and A5: Extract the Basic Metadata

Once you've got your PackageInfo object, pulling out the actual data you want is straightforward:

• Assign pi.packageName to a variable like %package_name
• Assign pi.versionName to %version_name
• Assign pi.versionCode to %version_code

At this point, you've officially got the package name pulled straight out of a standalone APK file, no installation required. This alone solves the original problem, but if you want to go a bit further and pull the human-readable app label too (which, trust me, is genuinely useful for display purposes), keep reading.

Handling Android Compatibility and App Labels (Android 10 vs 11+)

Here's where things get a little trickier, and honestly, this part took me the longest to figure out. If you try grabbing the app's human-readable label using the standard method, you'll often run into a runtime error, or worse, it just silently returns an empty string. This is because getApplicationLabel typically expects the app to already be installed, and since our APK is just a static file, Android doesn't have the context it needs to resolve the label properly.

The fix here involves a bit of reflection magic. Basically, you need to manually set a couple of fields on the ApplicationInfo object before calling the label loader. Specifically:

1. Set ApplicationInfo.sourceDir to %apk_path
2. Set ApplicationInfo.publicSourceDir to %apk_path as well

Once both of those are manually pointed at your APK's file path, you can then call appinfo.loadLabel(pm), and this time it'll actually resolve correctly, pulling the proper human-readable app name instead of throwing an error or returning nothing.

This little fix is honestly the difference between a half-working setup and one that actually behaves reliably across different Android versions, since without manually setting those source directory fields, the label loading step tends to fail more often than not, especially depending on whether you're testing on Android 10 versus Android 11 and up.

(Optional) Extracting and Saving the App Icon

If you want to take this even further and actually grab the app's icon too, not just its name and package info, that's totally doable, and honestly a nice finishing touch if you're building something like a custom APK browser or installer tool within Tasker.

Start by fetching the icon as a Drawable object using pm.getApplicationIcon(appinfo). Once you've got that Drawable, you'll need to convert it into something you can actually save as an image file, since Drawables themselves aren't directly exportable.

Depending on the icon type, you're generally dealing with either a BitmapDrawable or an AdaptiveIcon, and each needs slightly different handling. For a standard BitmapDrawable, you can pull the bitmap directly. For adaptive icons, though, you'll need to draw it onto a Canvas first to flatten it into a proper bitmap, since adaptive icons are technically layered objects rather than a single flat image.

Once you've got your final bitmap, whether pulled directly or flattened through a Canvas, you can export it as a .png file to your storage, giving you a clean icon image extracted straight from an uninstalled APK.

Why This Actually Matters

Honestly, once I got this whole flow working, it opened up a lot of possibilities I hadn't even thought about before. Being able to inspect standalone APK files without installing them first is genuinely useful if you're building any kind of file manager, APK organizer, or automated install verification system within Tasker. Instead of relying on file names alone (which can be renamed, misleading, or just plain unhelpful), you're now pulling accurate package names, version info, proper app labels, and even icons, straight from the source file itself.

READ ALSO: How to Enable blocked permissions for Modded APKs on android 13+

I know this setup involves a bit more legwork than just dragging in Tasker's built-in App Info action, but once it's configured, it works reliably and gives you way more control than the built-in tools ever could when it comes to standalone APKs. If you've been stuck on this same problem like I was, searching around and coming up empty, hopefully this saves you the hours of digging I had to do to piece this together. Give it a shot, and once it's set up, you'll wonder how you managed without it.