You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AGP allows generating a "Dynamic Feature", a pice of app code and resource which is distributed apart from the main app.
Unfortunately, the com.chaquo.python plugin can't actually be applied to a com.android.dynamic-feature one: the above example fails with the message:
A problem occurred configuring project ':myOwnDynamicFeature'.
> Chaquopy requires one of the Android Gradle plugins. Please apply one of the following plugins to ':myOwnDynamicFeature' project: [com.android.application, com.android.library]
(besides, this message is a bit mesleading, since the com.android.dynamic-feature plugin is an "Android Gradle" one...)
The common work-around consists in referencing a module applying both com.android.library + com.chaquo.python from the one applying com.android.dynamic-feature. In example:
':df' project gradle file (the Dynamic Feature module):
AGP handles com.android.dynamic-feature modules in a special way, allowing them to depend on the ':app' project while limiting the code emitted in their dex files to classes not already borrowed by the app itself.
Unfortunately, this isn't the case for the ':chaquopy' project in the above example:
it can't reference the ':app' project: it would cause a circular reference, and
every dependency it references is easily going to be put in its dex file, resulting in a Type already defined error during execution of the :app:l8DexDesugarLibRelease task.
Also note that the com.chaquo.python plugin itself injects some references to external Android modules, making even more difficult to work-around doubled-defined types.
It seems to me that making the com.chaquo.python plugin "compatible" with the com.android.dynamic-feature one would be much less trouble prone than the actual work-around.
The text was updated successfully, but these errors were encountered:
It seems to me that making the com.chaquo.python plugin "compatible" with the com.android.dynamic-feature one would be much less trouble prone than the actual work-around.
I agree that would be preferable, and I don't remember exactly why we don't support this.
You're correct about the general idea of the workaround, and I think you could get it working with some small changes. In fact, we have a test here which uses the same approach, with a couple of differences:
The dependencies keyword is implementation, not implements.
The app module does not directly depend on the dynamic feature module. Instead, it lists it in the dynamicFeatures setting. This should avoid the circular reference issue.
"implementation", right. I messed it up in pasting an example here.
My example doesn't show an excerpt of the app module config, in which you are right that dynamicModule shall be used to refer to the df module.
What I meant to show there is that attempting to reference the app module from the chaquopy one causes a circular dependency.
I would expect that one is using the chaquopy plugin for something needing some kind of interaction with the rest of the app, which would need a reference to the app module. Which the df module supports, while the chaquopy one doesn't.
A chaquopy plugin supporting the dynamic-feature one would overcame this problem.
Chaquopy version
15.0.1
Relevant parts of your build.gradle file
Describe your issue
AGP allows generating a "Dynamic Feature", a pice of app code and resource which is distributed apart from the main app.
Unfortunately, the com.chaquo.python plugin can't actually be applied to a com.android.dynamic-feature one: the above example fails with the message:
(besides, this message is a bit mesleading, since the
com.android.dynamic-feature
plugin is an "Android Gradle" one...)The common work-around consists in referencing a module applying both
com.android.library
+com.chaquo.python
from the one applyingcom.android.dynamic-feature
. In example:AGP handles
com.android.dynamic-feature
modules in a special way, allowing them to depend on the ':app' project while limiting the code emitted in their dex files to classes not already borrowed by the app itself.Unfortunately, this isn't the case for the ':chaquopy' project in the above example:
:app:l8DexDesugarLibRelease
task.Also note that the
com.chaquo.python
plugin itself injects some references to external Android modules, making even more difficult to work-around doubled-defined types.It seems to me that making the
com.chaquo.python
plugin "compatible" with thecom.android.dynamic-feature
one would be much less trouble prone than the actual work-around.The text was updated successfully, but these errors were encountered: