IssueTracker

sgtm, we can add the same API for FileSpec:

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:room/compiler-processing/src/main/java/androidx/room/compiler/processing/XFiler.kt;l=28?q=XFiler.kt&ss=androidx%2Fplatform%2Fframeworks%2Fsupport

I recommend using github for a small checkout size: https://github.com/androidX/androidx

Looks like we do have kotlin poet in the repo: https://github.com/androidx/androidx/blob/androidx-main/buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt#L75

So just need to add it as an API dependency to the room-compiler-processing's build file.

If you can add a test to the generated code match test, that would be great: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:room/compiler-processing-testing/src/test/java/androidx/room/compiler/processing/util/GeneratedCodeMatchTest.kt

lmk if you hit any blocker in getting started, thanks!

All

Brining over from dup:

• Note that there's also [Internal ref: b/63761003] to convert the resources into vector drawables. We should probably take another look at that first, since it's a lot less disruptive and may make splitting the module unnecessary.
  • Observation: This is not necessarily true as the ui module might also bring other dependencies (e.g. app compat) that are not necessary in the core module.
• It's highly likely this will be necessary for compose support.

#2 is your fork public?

No because I apply my own formatting rules + ugly workaround for https://issuetracker.google.com/issues/347336264 + they recently changed getRouteName to use string ressources that I do not care about and so hardcode them.

With that said, on recent versions except the ANR they have fixed all the previous NPE that I workarounded, so building a raw simple fork is easy, delete the ui folder, cleanup res folder and remove all no more needed stuff in build.gradle.

Thanks for the info!

@Google are you open for external contributions, for either the resource migration or the split of mediarouter?

the resource migration

Are you referring to the migration to drawables? If not can you spell this out?

Aside, I don't think we are in a condition to take contributions for the splitting, because we need to figure out how to ensure we keep a reasonable dependency story, which is something that we need to define ourselves, and probably the most complex bit about this.

I'm sorry we haven't been able to prioritize this so far.

we need to figure out how to ensure we keep a reasonable dependency story,

What do you mean by this ? You can create a mediarouter-core and mediarouter-app (Imo name to define to better reflect and future mediarouter-compose) and just have the current module have transitive usage of the new modules.

The only thing is to split the strings in whatever solution you have for the translations.

Are you referring to the migration to drawables? If not can you spell this out?

Indeed, I was talking about the migration from png to vector drawables, as mentioned in the first point in #5.

I see that there is already a mix of PNGs/vector drawables: https://github.com/androidx/androidx/tree/androidx-main/mediarouter/mediarouter/src/main/res

So probably some PNGs can be removed in favor of the corresponding vector drawables, and the rest will need to be replaced with new vector drawables.