1. Can it parse Intent-Filters?
2. How is it in terms of memory? I remember the original library (for PC) was quite memory consuming, which caused OOM sometimes when I tried it on Android: https://github.com/CaoQianLi/apk-parser/issues/19
3. Can you please put a sample too, and not just a library? Also, can you split the code , so that it would be possible to use via gradle? Maybe via https://jitpack.io/ ?
4. What about the license? Does it require to put info about the repo in the "about" screen of apps, or something?

For example, if all I want to get from the APK is the intent-filters, if you remove the code of ApkParser.parseResourceTable() , it will save a lot of memory and time for parsing the APKs.

For example, to demonstrate the time difference, I've ran this code on each of the apps that are installed on my device:

                ApkParser apkParser = ApkParser.create(packageInfo.applicationInfo.publicSourceDir);
                try {
                    AndroidManifest androidManifest = apkParser.getAndroidManifest();
                    for (AndroidComponent component : androidManifest.getComponents()) {
                         //nothing
                    }

This took 115,992 seconds to run the code on 241 installed apps (both system and user apps), yet it took 22,864 seconds when removing the code I've written about.

This is about 5 times faster.

It might even be possible to avoid calling other pieces of code, if all I want to get is the intent filters.

Hi @jaredrummler

I was wondering what the advantages of are of this library in comparison to getPackageManager().getPackageArchiveInfo(). Can you make a small comparison? Currently I am wondering why APKParser exist. What are the drawbacks of getPackageArchiveInfo?

Added attribute for intent filter as now you can set android:autoverify=true for intent filters from android marshmallow onwards. It is a new feature by google called app links. The documentation is available here https://developer.android.com/training/app-links/index.html

For example like this website:

http://www.javadecompilers.com/

I tried to use the library to get to the dex files, hoping it's the classes, but I got Chinese/Japanese strings:

        thread{
            val appInfo = packageManager.getApplicationInfo("com.whatsapp", 0)
            val apkParser = ApkParser.create(appInfo)
            val dexFiles = apkParser.dexInfos
            for (dexInfo in dexFiles) {
                val dexClasses: Array<DexClass> = dexInfo.classes
                val dexHeader: DexHeader = dexInfo.header
                Log.d("AppLog", "")
            }
        }

DeobfuscationSample.zip

Example is of Chrome and Chrome beta:

chrome and chrome beta.zip

The issue with those seems that it causes attributes to have namespace missing, as such:

<?xml version="1.0" encoding="utf-8"?>
<manifest http://schemas.android.com/apk/res/android:versionCode="398706833" http://schemas.android.com/apk/res/android:versionName="80.0.3987.68" http://schemas.android.com/apk/res/android:compileSdkVersion="29" http://schemas.android.com/apk/res/android:compileSdkVersionCodename="10" package="com.chrome.beta" platformBuildVersionCode="29" platformBuildVersionName="10">
...

Here's the full output of parsing Chrome beta using ApkParser.create(file).manifestXml :

chromeBetaManifestContent.zip

This is considered as invalid XML.

However, I've found a way to parse their manifest anyway. And it seems to fix this issue too .

I made a test, and it seems that I got it right for manifest files of both normal APK files and split APK files. This code is based on this solution on StackOverflow :

ApkManifestFetcher.zip

Please check it out.

Example attached:

split_delight.zip

The crash exception:

    java.lang.Error: com.jaredrummler.apkparser.exception.ParserException: Unexpected chunk Type:203
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1173)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:919)
     Caused by: com.jaredrummler.apkparser.exception.ParserException: Unexpected chunk Type:203
        at com.jaredrummler.apkparser.parser.ResourceTableParser.readChunkHeader(ResourceTableParser.java:204)
        at com.jaredrummler.apkparser.parser.ResourceTableParser.readPackage(ResourceTableParser.java:96)
        at com.jaredrummler.apkparser.parser.ResourceTableParser.parse(ResourceTableParser.java:67)
        at com.jaredrummler.apkparser.ApkParser.parseResourceTable(ApkParser.java:417)
        at com.jaredrummler.apkparser.ApkParser.transBinaryXml(ApkParser.java:269)
        at com.jaredrummler.apkparser.ApkParser.parseManifestXml(ApkParser.java:207)
        at com.jaredrummler.apkparser.ApkParser.getManifestXml(ApkParser.java:126)
        at com.android.apkinstalltest.MainActivity$onCreate$1.run(MainActivity.kt:33)
        at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:289)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) 
        at java.lang.Thread.run(Thread.java:919) 

Looking at the manifest xml string that it tried to build, I can see that its result is:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" xmlns:dist="http://schemas.android.com/apk/distribution" android:versionCode="11002120" android:versionName="1.1 (6007940)" android:isFeatureSplit="true" android:compileSdkVersion="29" android:compileSdkVersionCodename="10" package="com.google.pixel.livewallpaper" platformBuildVersionCode="11002120" platformBuildVersionName="1.1 (6007940)" split="delight" split="delight">
	<uses-sdk android:minSdkVersion="28" android:targetSdkVersion="28" />
	<dist:module dist:onDemand="true" dist:title="resourceId:0x7f0d006b">
		<dist:fusing dist:include="false" />
	</http://schemas.android.com/apk/distribution:module>
	<application android:hasCode="false">
		<meta-data android:name="com.android.vending.derived.apk.id" android:value="1" />
	</application>
</manifest>

But according to some online tools, it should have been:

<?xml version="1.0" encoding="utf-8"?>
<manifest android:versionCode="11002120" android:versionName="1.1 (6007940)" android:isFeatureSplit="true" android:compileSdkVersion="29" android:compileSdkVersionCodename="10" package="com.google.pixel.livewallpaper" platformBuildVersionCode="11002120" platformBuildVersionName="1.1 (6007940)" split="delight" split="delight"
  xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:dist="http://schemas.android.com/apk/distribution">
    <dist:module dist:onDemand="true" dist:title="@2131558507">
        <dist:fusing dist:include="false" />
    </dist:module>
    <application android:hasCode="false">
        <meta-data android:name="com.android.vending.derived.apk.id" android:value="1" />
    </application>
</manifest>

Somehow it got </http://schemas.android.com/apk/distribution:module> instead of </dist:module> .

So this makes it a non valid XML content. Also I noticed other differences, such as "resourceId:0x7f0d006b"

Use InputStream , DocumentFile or Uri instead.

The reason: In the near future, Google will block storage permission, which requires developers to handle files outside of the scope of the current app, to use SAF instead of File and file-path. More information here: https://issuetracker.google.com/issues/128591846

And yes, it's very devastating for many apps and libraries that need to access the files in a normal way. Even the Android framework isn't ready for it, as there are functions such as getPackageArchiveInfo (here) that uses a File or file-path, and have no other alternative.

If you want to test your solution without the storage permission and using just the InputStream, here (the app assumes there is a file named "a.apk" on the root path of the normal storage) : https://issuetracker.google.com/issues/132481545#comment5

Migrate to GradleMavenPush https://github.com/Vorlonsoft/GradleMavenPush

Reasons:

• Old plugin don't have updates for 4 years
• Better javadocs generation
• Better pom file generation
• Smaller gradle.properties
• You can easy migrate from Maven Central to JCenter by adding to your code IS_JCENTER = true only and register at https://bintray.com/bintray/jcenter