summaryrefslogtreecommitdiff
path: root/rs/java/android/renderscript/ProgramVertexFixedFunction.java
diff options
context:
space:
mode:
authorChristopher Tate <ctate@google.com>2019-04-23 11:13:35 -0700
committerChristopher Tate <ctate@google.com>2019-04-26 13:40:12 -0700
commit6aab623ad82439125fbd2ac96c07153f1d8d6710 (patch)
tree25a9ace514c99ef174f9f0f1a372af0d31d4e3ad /rs/java/android/renderscript/ProgramVertexFixedFunction.java
parent5ad5cdc394a11cf31f65602f5fd1c0721c54a366 (diff)
Top apps may start fg services even when under bg restriction
We now apply bg restriction policy (appop) on being able to enter a foreground service lifecycle only when the app is not in a "top" i.e. directly user-facing state. This avoids breaking existing supported lifecycle guarantees involving the order of calls to startService(), startForeground(), and startForegroundService(). Briefly: there is a designed behavior in the following sequence: 1. startService(intent); 2. startForeground() on that service; then 3. startForegroundService(intent) The intentional behavior is that after step 3, the app is not required to call startForeground() *again,* redundantly; because that service is already in a fg lifecycle. However, new-in-Q code broke this pattern in the case where the user had imposed bg service restrictions on the app. For this and for semantic/model reasons, we now do not apply fg service start restrictions to the user-facing app, even if the at app is under bg execution restrictions. The app is not background at that time, so should not be expected to face a different execution environment. Bug: 130048629 Test: Foreground use of GPM under bg restrictions Change-Id: I0e8c308ac26211082a90c165a64d66b31ab804df
Diffstat (limited to 'rs/java/android/renderscript/ProgramVertexFixedFunction.java')
0 files changed, 0 insertions, 0 deletions