Force protobuf version to prevent Java-7 issue

[MuntashirAkon]

Description

aapt2-proto depends on protobuf-java 3.10.0 which is broken in Java-7 (Android only). This PR fixes the issue by updating proto-buf to 3.11.4

[MuntashirAkon]

Hi @skylot,
I am commenting here because the issue is related. It is necessary to apply some more fixes to get the core library to work in Android API < 26. I have studied a little and found that in older API (with desugaring enabled), mostly .forEach() and List.sort() methods are a problem. In my fork, I have created a utlity class namely CompatUtils which provides compatibility for the .forEach() and related classes, (and for List.sort(), Collections#sort() can be used). If the patch (the patch hasn't been published yet) is merged to this repo, then it would be easier for me to maintain an Android-specific fork of Jadx. Let me know what you think.
TIA.

[skylot]

@MuntashirAkon I have several concerns about your request:

1. Using jadx on Android will be hard because jadx uses lots of memory and will hit app memory limit very fast
2. Jadx can be compiled with Java 8 only features, and D8 can desugar all these features to a working code
3. Actual problem is that jadx uses java.nio and it is not supported by Android below API 26. And I don't think I want to rewrite all code to remove all NIO API.

So as conclusion: I don't recommend using jadx library on Android and for now it is only work for Android API >= 26.

[MuntashirAkon]

1. Using jadx on Android will be hard because jadx uses lots of memory and will hit app memory limit very fast

Jadx can have interesting use-cases. For example, converting a single Smali file to Java can be useful while exploring an APK. In one of my app (App Manager), I offer this feature using jadx-core and jadx-dex-input libraries. Simple features such as these do not consume much memory. There are also other apps that offer this using Jadx (but they are closed source).

2. Jadx can be compiled with Java 8 only features, and D8 can desugar all these features to a working code

Apparently, it can't. I have run lint checks and found the issues that I have mentioned earlier. I have already fixed all the issues by creating compat classes in my end.

3. Actual problem is that jadx uses java.nio and it is not supported by Android below API 26. And I don't think I want to rewrite all code to remove all NIO API.

I think you should, at least, consider replacing it with more abstract I/O API. For example, I also maintain an Android-specific fork of the AOSP's apksig library supporting API 21 and later. In this library, they have used DataSource which abstracts the underlying FileDescriptor, File*Stream, FileChannel, RandomAccessFile. In this case, you could also use an abstraction similar to AndroidX's DocumentFile to handle file management. I think this design will be fruitful in the future as new ideas will build up. While refactoring the code, I haven't found any special use (for example, random access of the file contents) of the java.nio or File API that cannot be replaced by an abstraction. (java.nio is already a good abstraction over any file system, but having a custom abstraction would surely make things more precise and clear about how files are managed.)

In my fork, I've been successfully able to remove all the java.nio dependencies from the jadx-core library. It isn't much difficult right now but it could be in the future.