Generate proguard rules

[dcharkes]

We should see if we can generate the proguard rules.

We don't want to generate everything though (whole Java / Android API). So we need to integrate into the Dart tree shaker. (Maybe generate annotations in JNIgen and recognize these in the Dart tree shaker.)

[mkustermann]

To be a bit more elaborate:

package:jnigen is generating dart bindings that reference Java classes/methods/fields. After tree shaking the Dart code, we should have a mechanism to see the left-over usages of Java classes/methods/fields and based on that generate a ProGuard rules (that is input to Java tree shaker).

The version of package:jnigen that is used to generate bindings may not even be accessible to the tree shaker (as it's only a dev_dependency of a transitive dep in the application's pubspec.yaml).

/cc @mraleph @alexmarkov May be input to discussion for more flexible tree shaker discussion.

[alexmarkov]

When there is a one-way dependency Dart -> JNI bindings -> Java, we can just inspect the tree-shaken Dart program (kernel file) and list used JNI bindings / Java classes/methods/fields, without altering tree shaker itself. I can suggest to create a separate post-processor which would take a tree-shaken kernel files or a separate pass over kernel AST which would run after tree shaker and print used bindings to a file. Flutter const_finder tool (https://github.com/flutter/engine/tree/main/tools/const_finder) works this way (although it would be better to put this kind of tooling into Dart SDK to avoid dependency on kernel AST which is somewhat private / implementation detail).

[mahesh-hegde]

Cross linking #640

The kotlin suspend fn's generate private functions which our bindings have to call.

That would require disabling proguard's obfuscation in order to keep these methods.