Hi all :android-wave: , Should we exclude generate...

# library-development

[Abhimanyu]

Hi all 👋 ,
Should we exclude generated files from databinding, dagger, etc in API dump when using kotlin binary compatibility validator plugin?

[mbonnin]

I think most of the time, those should be implementation details

[mbonnin]

Now the tools do not always allow to generate those symbols as internal. I had a similar issue with kotlinx.serialization

[mbonnin]

So "it depends" I guess? If you think users of your library have valid reasons to use those symbols, it's better to include them. If not, just "hope" that they are not using them (maybe generate them in some internal package if you can)

[Abhimanyu]

A minified example.

MyAnalytics

internal interface MyAnalytics {
  fun track()
}

MyAnalyticsImpl

internal class MyAnalyticsImpl: MyAnalytics {
  fun track() {
    // tracking code
  }
}

MyActivity

public class MyActivity: AppCompatActivity() {
  @Inject
  internal lateinit var analytics: MyAnalytics

  // Other code
}

MyAnalyticsModule

@Module
internal object MyAnalyticsModule {
  @Provides
  fun providesMyAnalytics(): MyAnalytics { 
    return MyAnalyticsImpl()
  }
}

I have classes like these in my library.
Though all are marked internal - Interface , Implementation class , Dagger Module , still the generated Dagger code is using public and so they are added to the API dump from Binary compatibility validator.

So, what is the recommended way to skip these from the API dump given the clients cannot use these.

From what I could see, apiValidation config for BCV does not support wildcard for ignoredPackages .

[Dan Rusu]

If these internal classes are used by public inline functions then changing them could break compatibility for your users. The safest approach is to validate everything