Open dcharkes opened 1 year ago
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.
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).
Cross linking dart-lang/native#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.
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.)