java.lang.SecurityException on specific device model [153246136]

Fixed

Bug

Status Update

No update yet.

Description

so...@gmail.com

created issue #1

Apr 6, 2020 04:00AM

Component used: work
Version used: 2.2.0
implementation "androidx.work:work-runtime:2.2.0"
implementation "androidx.work:work-runtime-ktx:2.2.0"
implementation "androidx.work:work-rxjava2:2.2.0"

Devices/Android versions reproduced on:
W1450 / Android 7.0 (NetworkType does not matter.)

It occurs on specific device model only.
And about 600 crashes occur per month.

The followings are stack trace.
Please check if it can be fixed.

--------------------------------------------------------------------------------------------------------
java.lang.SecurityException: {PACKAGE_NAME} was not granted either of these permissions: android.permission.CHANGE_NETWORK_STATE, android.permission.WRITE_SETTINGS.
at android.os.Parcel.readException(Parcel.java:1683)
at android.os.Parcel.readException(Parcel.java:1636)
at android.net.IConnectivityManager$Stub$Proxy.requestNetwork(IConnectivityManager.java:2343)
at android.net.ConnectivityManager.sendRequestForNetwork(ConnectivityManager.java:2917)
at android.net.ConnectivityManager.registerDefaultNetworkCallback(ConnectivityManager.java:3197)
at androidx.work.impl.constraints.trackers.NetworkStateTracker.startTracking(NetworkStateTracker.java:3)
at androidx.work.impl.constraints.trackers.ConstraintTracker.addListener(ConstraintTracker.java:8)
at androidx.work.impl.constraints.controllers.ConstraintController.replace(ConstraintController.java:7)
at androidx.work.impl.constraints.WorkConstraintsTracker.replace(WorkConstraintsTracker.java:5)
at androidx.work.impl.background.greedy.GreedyScheduler.schedule(GreedyScheduler.java:21)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:15)
at androidx.work.impl.WorkManagerImpl.rescheduleEligibleWork(WorkManagerImpl.java:4)
at androidx.work.impl.utils.ForceStopRunnable.run(ForceStopRunnable.java:9)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:1)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
--------------------------------------------------------------------------------------------------------

Comments

su...@google.com <su...@google.com> #2Apr 6, 2020 04:21PM

Status: Won't Fix (Infeasible)

Yigit, do you have time to fix it?

reemission of the same liveData is racy

so...@gmail.com <so...@gmail.com> #3Apr 7, 2020 10:16AM

yea i'll take it.

su...@google.com <su...@google.com> #4Apr 7, 2020 04:26PM

Assigned to su...@google.com.

Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.

so...@gmail.com <so...@gmail.com> #5Apr 7, 2020 04:31PM

just emitting same live data reproduces the issue.

@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}

ap...@google.com <ap...@google.com> #6Apr 7, 2020 05:40PM

Marked as fixed.

With 2.2.0-alpha04 (that use Main.immediate), the issue seems to be still there (I tested it by calling emitSource() twice, like your test case)

la...@gmail.com <la...@gmail.com> #7Mar 21, 2024 03:19PM

yea sorry immediate does not fix it.
I actually have a WIP fix for it:

https://android-review.googlesource.com/c/platform/frameworks/support/+/1112186

if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.

val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}

Issue 153246136