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
This is a cherry-pick of https://googleplex-android-review.git.corp.google.com/#/c/399886/
Instead of storing a kb layout per device descriptor (which is expected
to be unique), store it for each vendor/product. This way we can keep
a consistent layout between identical but physically different keyboards.
There are some corner cases this is expected to fail on, namely devices
that incorrectly have the same vendor/product id. Devices that don't
define a vendor/product id will continue to use the descriptor to store
layout files.
Change-Id: I1f2508561992080459310d5a644dad65a9c24f1a
The activity manager needs to set launchedFromPackage to be that of
the previous package in the case where flow has been redirected
through an intermediate activity.
Change-Id: I678fc2e7d984991ac715251a784ba7d7ccbf9fca
Under certain circumstances, the power manager might continue to
hold the display wakelock long after the display had been turned
off due to the mDisplayReady flag having an incorrect value.
1. An inverted conditional caused DisplayPowerState to incorrectly
signal the screen on ready state.
2. The DisplayPowerController failed to clear the block screen on
flag in the case where the screen was turned off before it became
unblocked from turning on. This could happen when the display was
rapidly turned on-off-on-off.
Bug: 13248135
Change-Id: I8faa3034695c83c8cd35613d81acccf40d22128d
Under certain circumstances, the power manager might continue to
hold the display wakelock long after the display had been turned
off due to the mDisplayReady flag having an incorrect value.
1. An inverted conditional caused DisplayPowerState to incorrectly
signal the screen on ready state.
2. The DisplayPowerController failed to clear the block screen on
flag in the case where the screen was turned off before it became
unblocked from turning on. This could happen when the display was
rapidly turned on-off-on-off.
Bug: 13248135
Change-Id: I8faa3034695c83c8cd35613d81acccf40d22128d
The window manager and view hierarchy currently disable all drawing
when PowerManager.isScreenOn() returns false so no drawing occurs
while dozing. This will be fixed in a future patch to take the
display blanking state into account correctly.
This patch is a workaround to unblock development in the meantime.
Bug: 13133142
Change-Id: I2dc0b422c77285e657d73adca2606aa68264d987
We'd otherwise leave the data dirs & native libraries
lying around. This will leave the app permanently broken
because the next install of the app will fail with
INSTALL_FAILED_UID_CHANGED.
Also remove an unnecessary instance variable.
Cherry-pick from master
Bug 13416059
Change-Id: I1e644aab74d5ea519231800915b39c2f55d043ae
Since Kitkat, an app pre-loaded under /system/priv-app/ has
FLAG_PRIVILEGED. However, if the app updated and the device
rebooted, privileged flag is unset from pkgFlags. This patch
fix issue to assign privileged flag when scanning the updated
packages.
Bug: 12640283
Cherrypick from master.
Change-Id: I833d94cd911693c9291e8204f63bd8de945dbba6
SO_BINDTODEVICE is not needed with policy routing.
SO_BINDTODEVICE was also used on the default iface which causes problems
when the default iface is IPv6 only and the socket tries to connect to a
IPv4 address.
Bug: 12940882
Change-Id: I5b2bde0ac5459433fc5749f509072a548532f730
We're getting signals from the radio and it sometimes drops out for
a while. This change will delay applying an empty country code
for 15sec but apply non-empty country codes immediately. It uses a
sequence number so we only apply the most recent change, even if
it's delayed.
Also secures the wifi call to set the country code as we can't
allow apps to set it willy-nilly.
bug:11062898
Change-Id: I610039a833e26d4c5c8b7b9ac1b7546f3c83446a
...broadcasted repeatedly at every boot time
Remember the last done pre-boot receivers, so that if we have
a new pre boot receiver appearing (without the platform version
changing), when we re-write the file of done receivers it will
contain all of them, not just the new one.
Change-Id: I4ed3478edc549d4b023ec4b3719111bc4d970ae4
Permission denied when trying to launch an activity from a notification
We don't remove pending intents when updating an app, which is necessary
to keep app widgets and other things working. However, when uninstalling
an app, we should clear out all of its pending intents.
Change-Id: I95067b31098115b5a7b127766fd093750063bbb8
This change fixes two problems - first, if you rebooted phone after
turning on Airplane mode, Wifi controller goes to ScanOnly mode which
may end up in Wifi radio transmissions. Secondly, because of this
incorrect state, the state machine doesn't turn on Wifi once Airplane
mode is turned off.
bug: 11409692
Change-Id: I55b4a5352a72a9c783e1b9891dd5363434585fb0
requestRouteToHost will only allow system applications to make routes
exempt from the VPN's routing rules.
If a VPN is currently running and a non-system app requests a route it
will only succeed if that host is currently covered by a VPN exempt
routing rule. Otherwise it will fail.
For example, if a VPN is running and the MMS network is brought online
those routes will be added as VPN exempt. If an application then tries
to request a route to a MMS endpoint it will succeed because the routes
already exist. If an application tries to request a route to a host
covered by the VPN the call will fail.
Bug: 12937545
Change-Id: If7bcec91bbb96c62c8fb69748c975847e6c00b6f
The calling package name will be used to check if an application is a
system application when deciding if a route should be exempt from VPN
routing rules.
Bug: 12937545
Change-Id: I2c09c875fe9bb9685871a0a801ddcbb32fc17405
This may mean that secondary networks have bad network settings,
but currently default settings are overriden by secondary nets
which seems worse.
bug:13211589
Change-Id: I08d56e618208781bf6b21a88663c2b8503a4f226
We need to specify "PBKDF2WithHmacSHA1And8bit" now in order to get precisely
the same output as was previously generated with "PBKDF2WithHmacSHA1". We
also now try both when it's ambiguous which was used to generate the archive
checksums.
Bug 12494407
Cherry-pick from master.
Change-Id: I2d6081dd62f50f7d493045150b327ed120de7abd
The ACTION_EXTERNAL_APPLICATIONS_UNAVAILABLE broadcast now uses the
EXTRA_REPLACING intent extra when it is sent as part of an upgrade operation
on a forward-locked application. Update PackageMonitor to recognize this
new information and express it appropriately to the observer.
Bug 11988313
Cherry-pick from master.
Change-Id: Iecea1876ffc918f23f9fa5845f1f89ed8d740dd5
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: I44ce250e0e1c2583836dc823d9a333dabec51df9
The power manager sends SCREEN_ON and SCREEN_OFF broadcasts
purely based on the current wakefulness state. In particular,
when the system is awake, we consider the screen to be on even
if the screen may actually be off due to the proximity sensor
or some other condition. Likewise when the system is dozing
or asleep, we consider the screen to be off although technically
it may still be on and dozing.
This behavior is maintained for compatibility with applications
that interpret screen on / off as an indicator of user presence.
As it happened, the value of PowerManager.isScreenOn() did not
always match the state indicated by the broadcasts under certain
situations. Instead, it was based on the desired screen state.
These states used to be closely correlated but the addition
of doze mode causes them to diverge in meaning.
One consequence is that wake events from input devices might not
always wake the device from sleep unless the display's power
state was actually DOZING or OFF even if the power manager's
wakefulness was already DOZING or ASLEEP. This is now fixed.
Change-Id: Ie819c6d2c5a9ffaaf3101c5dee93ff72e9bc9f30
