Feature request: Consider publishing LayoutLib as a separate artifact on maven.google.com [241795063]

Fixed

Feature Request

Status Update

No update yet.

Description

jr...@squareup.com

created issue #1

Aug 8, 2022 08:42PM

Currently, we push a relocated version of LayoutLib to Maven Central under app.cash to support https://github.com/cashapp/paparazzi.

We use layoutlib-prebuilt, which appears to have a disjoint Git history from layoutlib sources.

Example: https://android.googlesource.com/platform/frameworks/layoutlib/+log/cf966f2e235785273459270e14c93c2eb23e6f33 vs https://android.googlesource.com/platform/prebuilts/studio/layoutlib/+log/514d0f9b6677be97964df74dcdba5ae25833331c

Since we simply repackage the binary, we don't provide true javadocs and source artifacts to Maven Central which can make debugging a bit challenging.

Furthermore, Google has recently started tagging beta and canary releases of layoutlib (yay!) to maven.google.com. We'd like to start experimenting with these builds to avoid forcing developers to remain pinned on older compileSdks, while avoiding the pains of maintaining source and binary compatibility with Paparazzi development.

We have been planning to eventually port the layoutlib build scripts (including the create jar task, which does the bytecode magic on android.jar), but it would be much simpler and beneficial if this were a deployable artifact managed by Google's release team.

What we do today is:

clone layoutlib-prebuilt
republish layoutlib.jar on Maven Central
zip and republish the platform specific libraries + fonts + icu data as a separate artifact

This allows the Paparazzi (Junit rule) consumer to consume #2 and a platform-specific dependency from #3, the latter of which is transformed/unzipped into Gradle transforms directory for reuse/caching as a flat filesystem similar to how Android Studio's LayoutInspector/LayoutLib's RenderTask expects it to be today.

Ideally, if this feature request is considered, we'd love a similar artifact design to be considered.

Comments

au...@google.com <au...@google.com> #2Aug 8, 2022 08:47PM

It seems the print is benign so I'll remove it; Could be worth it to find out how the message carrying information about "cb 0" (0 is not a valid color buffer handle) ever arrives to that line though

kn...@google.com <kn...@google.com> Aug 8, 2022 10:46PM

Assigned to an...@google.com.

to...@google.com <to...@google.com> #3Aug 22, 2022 06:34PM

I don't think we should necessarily remove these messages from the emulator code since at least some of them may point to real problems. I'm going to make sure that they are not treated as errors in Studio.

jg...@google.com <jg...@google.com> Aug 23, 2022 11:04AM

Reassigned to jg...@google.com.

ra...@google.com <ra...@google.com> #4Aug 26, 2022 08:23PM

I agree with Sergey -- while I think it's fine to remove some logging messages that aren't necessary, the root problem here is that Studio shows everything emitted as if they are errors, with one notification bubble per message. We don't do that for other tools that Studio launches, and in particular, this isn't specific to the "cb 0" message I showed here; there were earlier (different) error messages during the boot as well.

au...@google.com <au...@google.com> #5Aug 26, 2022 08:25PM

This behavior was requested specifically by the emulator team (vharron@ iirc, so at least 3-4 years ago). Let me see if I have any more details on why this was requested.

ra...@google.com <ra...@google.com> #6Aug 30, 2022 05:50PM

I couldn't find any relevant threads. IIRC, the main concern at that time was that warnings at startup (e.g. missing acceleration) really needed to be bubbled up to the users. If that is not an issue anymore, and the emulator team only wants errors to be visible, then the proposed change SGTM.

au...@google.com <au...@google.com> #7Sep 2, 2022 05:18PM

Yes, I vaguely remember that in some cases, you'd hit run, and then the emulator would fail to start (for example aborting because of some missing thing it needed), so we needed a way to surface these reasons. I don't know if there are any fatal startup errors like this. It seems like there are several things we could do here:

(1) Simplest: just reroute the errors into the log, and if emulator fails to start, that's where people can look. (I think that's what Sergey has already implemented?)

(2) If emulator could update itself to prefix truly fatal error messages in some way (such as error:) and use that for only fatal/exit(-1) reasons, then we could multiplex the output -- errors are shown in notifications as today, everything else is silently dumped to the log

(3) Hold on to the emulator output, and if there's a problem starting the emulator (say if it exits within a few seconds), then show all the emulator output.

jg...@google.com <jg...@google.com> #8Sep 8, 2022 03:13PM

(1) ag/11396356 does write all emulator's messages into Studio log at INFO level.
(2) More discipline in the emulator's messages would definitely help. Right now they don't seem to follow any simple set of rules (the "Emulator: " prefix is added by Studio):

2020-05-06 11:07:04,587 [ 38858] INFO - manager.EmulatorProcessHandler - Emulator: /usr/local/google/home/sprigogin/Android/Sdk/emulator/emulator -netdelay none -netspeed full -avd Nexus_10_API_29 -no-window -gpu auto-no-window -grpc-use-token
2020-05-06 11:07:04,976 [ 39247] INFO - manager.EmulatorProcessHandler - Emulator: pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
2020-05-06 11:07:04,985 [ 39256] INFO - manager.EmulatorProcessHandler - Emulator: E0506 11:07:04.983601525 31440 socket_utils_common_posix.cc:201] check for SO_REUSEPORT: {"created":"@1588788424.983585430","description":"SO_REUSEPORT unavailable on compiling system","file":"/mnt/tmpfs/src/android/emu-master-dev/external/grpc/src/core/lib/iomgr/socket_utils_common_posix.cc","file_line":169}
2020-05-06 11:07:05,321 [ 39592] INFO - manager.EmulatorProcessHandler - Emulator: Your emulator is out of date, please update by launching Android Studio:
2020-05-06 11:07:05,321 [ 39592] INFO - manager.EmulatorProcessHandler - Emulator: - Start Android Studio
2020-05-06 11:07:05,321 [ 39592] INFO - manager.EmulatorProcessHandler - Emulator: - Select menu "Tools > Android > SDK Manager"
2020-05-06 11:07:05,321 [ 39592] INFO - manager.EmulatorProcessHandler - Emulator: - Click "SDK Tools" tab
2020-05-06 11:07:05,321 [ 39592] INFO - manager.EmulatorProcessHandler - Emulator: - Check "Android Emulator" checkbox
2020-05-06 11:07:05,321 [ 39592] INFO - manager.EmulatorProcessHandler - Emulator: - Click "OK"
2020-05-06 11:07:05,321 [ 39592] INFO - manager.EmulatorProcessHandler - Emulator:
2020-05-06 11:07:06,475 [ 40746] INFO - manager.EmulatorProcessHandler - Emulator: emulator: INFO: LoggingInterceptor.cpp:70: 1588788426470945, rcvTime: 84, sndTime: 995, UNARY, rcv: 24, snd: 12156, /android.emulation.control.EmulatorController/getStatus() -> [...], OK
2020-05-06 11:07:07,355 [ 41626] INFO - manager.EmulatorProcessHandler - Emulator: emulator: INFO: LoggingInterceptor.cpp:70: 1588788426597819, rcvTime: 34, sndTime: 12945, SERVER_STREAMING, rcv: 48, snd: 1104071, /android.emulation.control.EmulatorController/streamScreenshot(format: RGBA8888 width: 665 height: 1064) -> [...], OK

em...@google.com <em...@google.com> #9Sep 9, 2022 05:22PM

It might make sense to split the platform-agnostic data and native libs into separate artifacts to reduce duplication.

jo...@gmail.com <jo...@gmail.com> #10Apr 8, 2023 06:10AM

Hi, are there any updates on this issue? We still desire eliminating this step from our deployment process.

jg...@google.com <jg...@google.com> #11Apr 21, 2023 02:45PM

I'm working on getting the approvals for this, hopefully will be done soon

jg...@google.com <jg...@google.com> #12Jan 10, 2024 05:16PM

Marked as fixed.

Layoutlib is now published on GMaven as two artifacts:

com.android.tools.layoutlib:layoutlib
com.android.tools.layoutlib:layoutlib-runtime

jr...@squareup.com <jr...@squareup.com> #13Jan 10, 2024 05:26PM

Exciting! Re: versioning, I see that while layoutlib-api is on version 31.4.0-alpha03, layoutlib and layoutlib-runtime is on version 14.0.1. How will that separate versioning scheme map in terms of Android Studio and AGP release cycles?

jg...@google.com <jg...@google.com> #14Jan 10, 2024 05:55PM

The idea of the versioning of the new layoutlib artifacts is to indicate which version of the Android platform they are based on (14.0 for the current release) and not to tie it to releases of Studio, though the latest version of Studio would be using the latest version of layoutlib.
Would it be important for you to have a way of making a correspondence between versions of Studio and versions of Layoutlib?

jr...@squareup.com <jr...@squareup.com> #15Jan 10, 2024 06:10PM

Ok, makes sense. Re: importance, probably not, and I definitely prefer decoupling layoutlib's supported platform from the IDE!

jr...@squareup.com <jr...@squareup.com> #16Jan 11, 2024 07:13PM

Another question: is there any particular reason why the runtime jar bundles all the platforms, considering only 1 of them can ever be used on a given machine, vs having separate runtime jars? IIRC, Android Studio's installer will only install one, based on the detected OS from the download site. I understand that ultimately, the runtime jar should be unzipped and only the pertinent platform subdirectory will be loaded, but every version bump will result in downloading (N-1)/N platform bundles which will never be used.

Message last modified on Jan 11, 2024 07:17PM

jg...@google.com <jg...@google.com> #17Jan 11, 2024 08:13PM

The runtime artifact uses Gradle module metadata to handle different OS/CPU architecture. So there are actually 5 jars that are published:

one for linux/x86-64 (suffix linux)
one for windows/x86-64 (suffix win)
one for mac/x86-64 (suffix mac)
one for mac-arm64 (suffix mac-arm)
one that contains all the native libraries

If you configure your Gradle build to specify which OS/arch it is running on, it will only download the relevant jar. But if no configuration is specified, the default jar containing everything will be downloaded instead.
Otherwise you can add the configuration suffix after the version to download a specific one. e.g. "com.android.tools.layoutlib:layoutlib-runtime:14.0.1:linux" for the linux x86-64 version

au...@google.com <au...@google.com> #18Jan 11, 2024 08:28PM

In maven terms they are called classifiers

sz...@gmail.com <sz...@gmail.com> #19Jan 13, 2024 03:13AM

Remèlhetőleg a korábbi Remèlhetőleg az eszközrendszerek egymással kompatibilisebb tudásútvonalat, hatèkonyabb integrációt, ès további fejlődès kompatibilitást eredmènyez a
különböző operációs rendszer/CPU architektúrák kezelésére. Az èn esetemben ez lehet a megfelelő.
"com.android.tools.layoutlib:layoutlib-runtime:14.0.1:linux"linux x86-64 verzióhoz. Vèlemènyek, tanácsok ?

It is hoped that the tool systems will result in a more compatible knowledge path, more effective integration, and further developing compatibility in the
to handle different OS/CPU architectures. In my case, this might be the right one.
"com.android.tools.layoutlib:layoutlib-runtime:14.0.1:linux" for linux x86-64. Opinions, advice?