Currently we used global setting to restrict user from enabling oem
unlock. As global settings can be chagned using adb, using user
restrictions instead.
Bug: 29893399
Change-Id: Ic83112a4838b8279bf50408a29ae205e0b8639ee
setThreadGroup(TOP_APP) will place a thread in the fg stune group but
not the top_app cpuset. This allows android.ui to get more runtime to
render transitions between activities without impacting its CPU
placement.
bug 29512132
Change-Id: I95e031975f83290f88ac6e538abf1062aea27ed4
Add a new mode, controlled by sys.use_fifo_ui property, that enables the
top app's UI and RenderThread to be SCHED_FIFO. This eliminates almost
all jank due to scheduling competition with non-UI critical
threads. This mode may not be suitable for all devices.
bug 24503801
Change-Id: I7b8a31830ad80f7efa00236928d5476998ed4e00
Use this to make sure that the VR thread belongs to a given process when
it is assigned.
bug 28715706
Change-Id: I4e5b0d8493e69e443eb907f0a6f2a9482fb64bac
Refactor slightly to forbid using myUserId in the zygote (uid == 0).
Also factor Environment to put user data (vs shared data) into its
own class, which should keep the page the shared data is on actually
shared between processes.
Bug: 29338430
Change-Id: I05d1306b57658a83299e38076171f56cb364ea80
Adds a new API that enables device-specific scheduler optimizations for
latency-sensitive VR threads.
BUG: 29163534
Change-Id: I58d7be0eb266eca452c804cd07004784fb7daf2b
This will enable the developers to check if they could replace an unbuffered
I/O operation with a corresponding buffered I/O operation.
The policy can be set as follow:
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectUnbufferedIO().build());
Bug: 3018772
Change-Id: Ib804a8e9980ae40abfd216f8b87c250fd413bd5c
Add an API to query if the calling app is running
in a demo user sandbox. This allows apps to customize
the starting experience to a potential customer.
Change-Id: I50e40f9a8c66da4b5672c1dc64606d7bedba3f8c
Fixes: 29833923
We need to make every peniding intent that went in the notification
system to allow special handling of such intents when fired by a
notification listener. If a pending intent from a notification
is sent from a notification listener, we white-list the source app
to run in data saver mode for a short period of time. The problem is
that actions and the notificaion can have extras which bundles may
contain pending intents but the system cannot look into the bundles
as they may contain custom parcelable objects. To address this we
keep a list of all pending intents in the notification allowing
the system to access them without touching the bundle. Currently
the pending intents are written to the parcel twice, once in the
bundle and once as the explicit list. We can come up with a scheme
to optimize this but since pending itents are just a binder pointer
it is not worth the excecise.
bug:29480440
Change-Id: I7328a47017ca226117adf7054900836619f5679b
A notification is posted when the system storage gets too low.
Currently, it redirects into the Storage Settings. Instead,
it should redirect into the Deletion Helper to directly let the
user clear out their storage.
Bug: 29437277
Change-Id: I4e35adf300d5e479d4171f1e6f090f2a757400f2
We lost the code that checks to see if the target process still
exists and aborts trying to use it if so. To reduce the race
there, we have a new explicit check of the state of the process.
Hopefully fixes some of issue #28737082.
Change-Id: I37a7a6e9767516d564168ef5e110c4adafe3fb76
...as active for idle maintenance
Nor jobs of whitelisted apps.
Now they don't.
Also remove the no longer used "active download" tracking code.
Change-Id: I553197801f6eabaf15716f3201dd65257a0d4e94
