Request: make version of this repository for Android

[AndroidDeveloperLB]

One that will also accept InputStream instead of File.

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

[lxbzmy]

This project intend to parse apk file on j2SE application.
android app can parse apk use android API.

[AndroidDeveloperLB]

As I wrote, Android apps won't be able to do it using the API anymore, because the getPackageArchiveInfo function requires file-path, and the storage permission is planned to be deprecated in favor of a much more restricted API (SAF), which can't allow access to File or file-path.
So there will be no way to use those, and we will need to use inputStream, or copy the APK file to the path of the current app, which is a waste.

[lxbzmy]

Oh , bad news.
Got it.

[AndroidDeveloperLB]

Can you somehow support InputStream and not just File or file-path?
This change broke already so many apps (including of Google) on Beta 2 . On Beta 3 Google decided to delay this issue.
I think many libraries depend on File API, and that Google shouldn't have gone so far.

[lxbzmy]

Support InputStream needs some work, I can afford.
Further, some of library depends on outdated(4years). These library need update to support new version of apk, these work need more time.

[AndroidDeveloperLB]

I would really appreciate it.
Alternatively, you could find a workaround to still use PackageManager of Android.

[AndroidDeveloperLB]

Here, I've asked about it on StackOverflow :
https://stackoverflow.com/q/56309165/878126

[lxbzmy]

Maybe copy input stream to a temp file is a quick solution.

[AndroidDeveloperLB]

My app returns a list of all APK files that it can find on storage, and information about each.
It's not a good solution to copy each APK file just to get information about it.
The files already exist.
I also wrote about it on the question. I want to avoid using File and file-path, because there is no API for SAF that returns such a thing that I can really access.
I can't use the normal File or file-path anymore :(

[lxbzmy]

May be copy input stream to temp file, and then parse it , a better solution?

[AndroidDeveloperLB]

It's still a new file, for each file that the user has.
So if the user has 100 files, I have to copy 100 files, and for each parse.
That's instead of just parsing each file directly.

[lxbzmy]

I inspected code, apk file read by parser many times. eg. AssetManager is based on file operation, contains scan zip entry. it's hard to done work on input stream once.
It's hard work to get all resource from input stream(All data need read into memory from input stream). If input stream support reset, there may be a hope.

[AndroidDeveloperLB]

Well, even if it doesn't, you can create the inputStream over and over again.

You could have an interface that uses a function to re-create the inputStream.