This change applies a relabel to both /data/data and
/data/user directories on boot. Not every boot will
apply this relabeling however. The appropriate
seapp_contexts is hashed and compared to
/data/system/seapp_hash to decide if the relabel
should occur.
Change-Id: I05e8b438950ddb908e46c9168ea6ee601e6d674f
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Add a new hidden method to recovery system to trigger a factory reset
followed by a shutdown, rather than a reboot back to the regular
system. Use this flag when the MASTER_CLEAR intent is broadcast with
a boolean extra "shutdown" set to true.
Change-Id: I2ceb25b715d9f0ef492a75b3d287d1e17cec89ef
This is a start and two tests succeed:
Tested expired AT&T SIM and waiting 15min for alarm to fire.
Tested a provisioned Verizon SIM and works normally.
I've NOT tested AT&T where I've properly completed the provisioning.
I've NOT tested T-Mobile SIM either provisioned or not-provisioned.
I've NOT tested provisioning over WiFi.
I've NOT tested that WiFi <-> Mobile works
I've NOT tested voice calls, SMS, MMS
...
The current bug is below, but it is poorly named either it should be
renamed or a new bug created.
Bug: 13190133
Change-Id: I0a09f642614cd27a8655e9dae764b8999ce485b8
When persistent process with Service restarts, ActivityManagerService
does not reset ProcessRecord#hasClientActivites to false
(because ProcessRecord of persistent process is continued using
after killing).
It disturbs updating LRU list in ActivityManagerService, and then,
when new process calls ActivityManagerProxy#publishContentProviders,
SecurityException happens because of no entry in the list.
Bug: 13517358
Change-Id: I46b064f71a4f7025ade1bf117801352a7ab22e6a
Adapted from change I44ce250e, "Maintain binding to crashed
listeners from NotificationManagerService.":
> This fixes the logic on the death handlers for notification
> listeners, and doesn't unbind from the listener services so
> that the system will bring them back up again.
Bug: 12587702
Change-Id: I41d0c6733046ee9760bcfae4407e754592b805ea
A VPN can once again bring up a new tun interface while the old tun is
running. Once the new tun is set up the routing rules will be removed from the
old tun. It is up to the application to drain the old tun of traffic and
close it.
If the new tun fails to come up the old tun will remain untouched and
can still be used.
To prevent leakage the new rules are added before the old tun is
shutdown. Netd/Dns has been changed to allow multiple rules to exist
at once with the most recently added rule taking priority.
Bug: 12134439
Change-Id: I7e00c7c68cc339d81f09b3d2a33276ffc76985f5
With netd allowing overlapping rules for uid range rules the interface
name is needed to make sure only the correct rule is removed.
Bug: 12134439
Change-Id: I94f77f154f49ca8d5f6cf49683a4473cc92c3eb7
When Intent.FLAG_ACTIVITY_REORDER_TO_FRONT was set the TaskRecord
member frontOfTask was being set true incorrectly for the top
activity. It should only be true for the bottom activity. This fix
ensures that frontOfTask is always set correctly for all activities by
consoldating it into one method.
Fixes bug 12171535.
Change-Id: If982dad3c81b2b816adc5d89e7e0496923098a70
For managing the ui mode, consider the device to be a television if it
has either the FEATURE_TELEVISION or FEATURE_LEANBACK system features.
When leanback is available for non-television devices, we need to
reconsider the use of these features for setting the television ui mode.
Change-Id: I7b82372ce19067e010be9b42111816bab186f95b
When a client of the NsdService exits, NsdService should
clean up the requests it has sent to the mDNS daemon:
cancel any pending resource-discovery and resource-resolution
queries, and remove any services registered by this client.
If this isn't done, several bad things happen. The daemon will
continue to run unnecessarily, will report service discoveries
that can't be forwarded on to the client, and will continue to
advertise service ports for an application which is no longer
running until the device is rebooted (mDNS pollution).
Bug: 9801184
Change-Id: I0aa7311480322aefcff16f902fbbf34f50985d38
The value for the TCP initial receive window comes from,
in order,
kernel
/proc/sys/net/ipv4/tcp_default_init_rwnd
init.rc (via properties)
net.tcp.default_init_rwnd
properties
net.tcp.default_init_rwnd
gservices
Settings.Global.TCP_DEFAULT_INIT_RWND
Bug: 12020135
Change-Id: I0e271be19472900fa9f3bab037d53383ec014a9e
