Request: split UnApkm function to use streams instead of files

Question

Request: split UnApkm function to use streams instead of files

AndroidDeveloperLB opened this issue 5 years ago · 6 comments

AndroidDeveloperLB commented 5 years ago

Not forcing to save to a file, and not forcing to have an input file.
Streams are more general, and this one could be useful in case the input is from SAF or even inside a zipped file.

Answer 1 · 2020-03-27T08:59:03.000Z

Maybe even provide a way to get to the various APKs inside, to be able to choose which to extract, before actually extracting them.
This could be useful in case we want to extract only the base APK, for example. However, sadly I don't think there is an easy&reliable way to determine which is the base APK, without actually parsing its manifest file...

Answer 2 · 2020-03-27T09:32:08.000Z

I will try to think about how best to do this!

Maybe even provide a way to get to the various APKs inside, to be able to choose which to extract, before actually extracting them.

This I think would be beyond the scope of this project, it should be fairly simple to do with a ZipInputStream

Answer 3 · 2020-03-27T09:56:18.000Z

Added to af1e936 and the function to read/write from files has been rewritten to use this Streams interface instead.

Answer 4 · 2020-03-27T10:04:41.000Z

I see.
This is a nice approach. Thank you for this.

As for ZipInputStream, this is a good idea, but I wonder if the current code could be better for this, as on some scenarios it might take a toll on performance.
Could it cache the data from before the loop, so that the ZipInputStream could be created quickly, over and over, after the first initialization?
Or does it need to be re-initialized each time you want to go over the file content?

The purpose of what I write is to reach the same performance as ZipFile, at least after the initialization .

Answer 5 · 2020-03-27T10:32:54.000Z

Thanks. Have added some convenience functions in 2f85794 to allow for processing the header and then re-using this.

decryptStream(InputStream i) process normally, while decryptStream(InputStream i, Header h) uses the provided key and skips the header, but expects a similar input stream to the first one (skips over the first few bytes and avoids the expensive operation)

Answer 6 · 2020-03-27T10:52:24.000Z

Oh this is actually great, as I actually asked about this here:
#4 (comment)