Fixed
Status Update
Comments
ky...@bytedance.com <ky...@bytedance.com> #2
This was fixed by aosp/1331903 and will be available in the Lifecycle 2.3.0-alpha04 release.
rk...@google.com <rk...@google.com>
rk...@google.com <rk...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-master-dev
commit f891d66d44417ae7298d8306dc5cbca9cfe4b1ee
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Jul 08 14:20:29 2020
Fix lifecycle-livedata-core-ktx-lint ObsoleteLintCustomCheck
Using the latest version of lint-core (27.1.0) as a dependency for the
livedata-core lint rule causes an ObsoleteLintCustomCheck for studio 4.0
and 4.1 (along with the subsequent gradle versions).
Instead of using the latest, using the minimum version seems to work
appropriately.
Added a lintMinVersion variable to the dependcies file and used that to
make updating easier.
Test: tested in studio 4.0 and 4.1-Canary 8
Bug: 158699265
Change-Id: If1636b3e08a368cf25fb268f42754c4c6ff2f463
M buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt
M lifecycle/lifecycle-livedata-core-ktx-lint/build.gradle
https://android-review.googlesource.com/1358530
Branch: androidx-master-dev
commit f891d66d44417ae7298d8306dc5cbca9cfe4b1ee
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Jul 08 14:20:29 2020
Fix lifecycle-livedata-core-ktx-lint ObsoleteLintCustomCheck
Using the latest version of lint-core (27.1.0) as a dependency for the
livedata-core lint rule causes an ObsoleteLintCustomCheck for studio 4.0
and 4.1 (along with the subsequent gradle versions).
Instead of using the latest, using the minimum version seems to work
appropriately.
Added a lintMinVersion variable to the dependcies file and used that to
make updating easier.
Test: tested in studio 4.0 and 4.1-Canary 8
Bug: 158699265
Change-Id: If1636b3e08a368cf25fb268f42754c4c6ff2f463
M buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt
M lifecycle/lifecycle-livedata-core-ktx-lint/build.gradle
rk...@google.com <rk...@google.com> #4
There was a use of a lint version that was too new to work in older studio versions. This has now be fixed and will be released in the Lifecycle 2.3.0-alpha06 release.
Description
AutoLock
appears to be a custom implementation ofstd::unique_lock/lock_guard
. It does, however, a method namedisLocked()
. There is only one use of the method at the moment:I believe, that has room for improvement. Firstly, even if we checked
isLock()
in general, asisLock()
is not thread-safe, there is no guarantee (in general) that the same thread can then lock it. It is only useful when there is only one thread that locks/unlocks the givenAutoLock
object and the thread wants know whether thelock
is acquired or not by itself. I don't think that's useful. I think the method being public, it has a good chance to confuse external developers.My belief is that the
AutoLock
should be simply replaced withstd::unique_lock
and/orstd::lock_guard
, as many uses of the class do not calllock
orunlock
. And,isLocked()
should be removed. The only call site should be implemented without that.Aside from all mentioned above, I am trying to compile the code with
--enable-thread-safety-checks
, and the first code that blocked the compilation on Linux was the use ofisLocked()
.