IssueTracker

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

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.

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.

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.

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.

Yes, the @SuppressLint of the inflation.

Yes, we use lint, as do most users, and lint has thousands of unit tests, but this bug exposes a specific scenario that went undetected.

The reason this happens is that that annotation is on an expression; that's not a super common scenario (and is not possible in Java). This triggered a bug in UAST; I linked to the bug report above. And the symptom when this happens is that the annotated statement disappears from the parse tree. So it's not like when this happens you get some weird error; instead, the problem is that code in these statements aren't analyzed, so lint wouldn't be able to for example flag a problem on that line. That's not the kind of thing that's easy to spot.

Anyway, I've tried to fix this in the Kotlin source tree and have sent a patch to JetBrains. In the meantime, my patch fixes this bug and passes all existing unit test, so I've applied it to Studio's copy of uast for now, and have cherrypicked it back to the 4.0 branch as well. So this will be fixed in an upcoming 4.0 beta/rc and 4.1 canary by Change-Id: I83a509d73e777bcee281b99934bce086e79a3677.

I confirmed that the sample project you attached to this bug doesn't show any unused resources when running with lint with this fix.

Which comment was that, #5? I don't think lint will flag that as an unused resource.

One of those two bugs is a duplicate of the other, and neither one is similar to the scenario in #5. I tried to reproduce #5 and it does not remove the resource referenced only within the if (BuildConfig) block.