Should apps that define their own non-Material design system be using the new profile rules to creat...

# compose

[Bryan Herbst]

Should apps that define their own non-Material design system be using the new profile rules to create ART profiles for key theming Composables (e.g equivalents of MaterialTheme)?

If so, do profile rules work in a library module (i.e. modules that are not packaged as AARs)? The release notes specifically say “Libraries can define these rules which will be packaged in AAR artifacts”, which seems to indicate perhaps not.

[kevindmoore]

Libraries are packaged as AAR files. Are you thinking of APK files?

[Bryan Herbst]

That’s exactly what I’m asking- if my library is not packaged as an AAR (i.e. it is a Gradle module packaged directly into the APK) will these profiles still work as described? And should we be using them?

[tad]

I thought that was just explaining that libraries can include those rules and they'll be merged into the final APK, similar to proguard rules

[tad]

In any case, I would be surprised if the merging behavior depends on if your libraries come from Gradle projects or external AARs

[tad]

Unless they wrote something completely separate from the existing merge pipeline in AGP

[Bryan Herbst]

AARs are consumed slightly differently from modules- private resources for example are not actually private in a module but are when consumed as an AAR. That was one of my main reasons for asking- this is also a bit more difficult to test.

[tad]

That is a specific and complicated case due to how AAPT and the resource loading systems work. For things like proguard rules and manifests, which are very similar to ART profiles, the same merge pipeline is used for both internal and external artifacts.

[tad]

But for testing, you can try adding a profile to one of your library modules, running a build, and inspecting the APK