Skip to content

build: check the public API of the library modules - #1067

Merged
dkhawk merged 1 commit into
mainfrom
build/binary-compatibility-validator
Nov 3, 2026
Merged

dkhawk merged 1 commit into
mainfrom
build/binary-compatibility-validator

Conversation

@kikoso

@kikoso kikoso commented Nov 3, 2026

Copy link
Copy Markdown
Collaborator

Summary

maps-compose has no check on its public API today. AGENTS.md says public API changes must be additive and backward compatible, but nothing enforces it, so an accidental break (a removed overload, a changed parameter type, a default that moved) would only be found by users after a release. android-maps-utils already guards this with the binary compatibility validator; this PR sets up the same thing here.

  • org.jetbrains.kotlinx.binary-compatibility-validator 0.18.2, same version as android-maps-utils.
  • PublishingConventionPlugin registers apiBuild, apiDump and apiCheck for each library module, reading the release classes.jar, exactly like android-maps-utils does (the plugin's own Android integration does not fit AGP 9 built-in Kotlin). check depends on apiCheck, and there are root apiDump/apiCheck tasks for all modules.
  • The current public API is committed in maps-compose/api/maps-compose.api (319 lines), maps-compose-utils/api/maps-compose-utils.api (51) and maps-compose-widgets/api/maps-compose-widgets.api (6). The generated R classes and their nested classes are ignored, since they are public in bytecode but not part of the API.
  • CI runs apiCheck in the test workflow.
  • AGENTS.md explains when to run apiDump.

A few points worth to mention

  • The .api files are also a nice snapshot of what we expose today. It is worth a quick look: some things are public only for technical reasons (i.e. ComposableSingletons$GoogleMapKt, generated by the Compose compiler).
  • The check compares binary signatures. Renaming a parameter keeps the signature, so it passes, but it still breaks callers using named arguments. AGENTS.md mentions it so we keep an eye on it in review.

Testing

  • ./gradlew apiDump generates the three files, and ./gradlew apiCheck passes on them.
  • Adding a required parameter to ScaleBar makes :maps-compose-widgets:apiCheck fail with the old and new signatures; reverting it passes again.
  • ./gradlew build apiCheck (same as the updated CI command) and spotlessKotlinCheck pass locally.

Add the binary compatibility validator, set up the same way as in
android-maps-utils: apiBuild, apiDump and apiCheck per library module, reading
the release classes jar. Commit the current API of maps-compose,
maps-compose-utils and maps-compose-widgets in api/<module>.api and run apiCheck
in CI, so a public API change shows up in review and an accidental break fails
the build.
@kikoso
kikoso requested a review from a team as a code owner November 3, 2026 09:51
@github-actions

github-actions Bot commented Nov 3, 2026

Copy link
Copy Markdown

Coverage (unit tests)

Compared against 174f0fd on main (#1060).

Module Line % Change Branch % Change
maps-compose 15.28% no change 3.76% no change
maps-compose-utils 6.09% no change 4.47% no change
maps-compose-widgets 10.88% no change 11.11% no change
TOTAL 12.99% no change 4.12% no change

Line and branch coverage from unit test reports. History is recorded on the coverage-history branch after each merge to main.

@googlemaps-bot

Copy link
Copy Markdown
Contributor

Coverage (instrumentation tests)

Overall Project 43.69% 🍏

There is no coverage information present for the Files changed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants