The test in layoutlib bridge has been updated to check the return
value of the delegate method match the value of the overriden method.
This changeset also fixes the problems found due to this change.
Change-Id: I87cef323c4eaee4e9f60475f01156b276593fa50
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
* commit 'bbfc08b3abc0934f67659f3238eb79dcac838c17':
open("/dev/rtc0") failure in AlarmManagerService.setTime() should be non-fatal
Move time setting code from SystemClock to AlarmManagerService
* changes:
open("/dev/rtc0") failure in AlarmManagerService.setTime() should be non-fatal
Move time setting code from SystemClock to AlarmManagerService
BackupDataReader / BackupDataWriter were implicitly assuming that when
instantiated, the underlying fd was positioned at start-of-file. If one
tried to e.g. open an existing data stream to append further data to it,
things might randomly fail (at read time, possibly when consuming the
stream later) due to incorrect alignment of the data entities: the
appending writer would assume that no padding was needed to achieve
correct alignment, and this might easily be false.
Now the underlying native reader/writer helpers recognize the true
position within the file when constructed, and as a result it's now
safe to e.g. construct a BackupDataOutput for an existing file and
then append to it.
Change-Id: If0484921e687852f923a4b4efabff573a6c16981
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
Setting the time-of-day clock is still useful on systems where the RTC
device is not yet brought up or otherwise unavailable. This matches the
in-kernel behavior of the Android alarm driver.
Change-Id: I6d4fdadab12e241ada7419425efd55bd13873c55
Signed-off-by: Greg Hackmann <ghackmann@google.com>
On devices using /dev/rtc instead of /dev/alarm, updating the
time-of-day clock and RTC are separate syscalls. Hence the clock and
RTC could be left in inconsistent states if two threads called
SystemClock.setCurrentTimeMillis() simultaneously.
By moving this code into AlarmManagerService, we can put a global lock
around AlarmManagerService.setTime() and prevent the race condition.
Note that access to SystemClock.setCurrentTimeMillis() is now gated by
android.permission.SET_TIME, where before it was gated by filesystem
permissions (i.e., could the process write to /dev/alarm or /dev/rtc).
Change-Id: Ia34899a4cde983656305fd2ef466dfe908ed23c8
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Those intent handlers are persistent preferences. They will remain the default intent
handler even if the set of potential event handlers for the intent filter changes
and if the intent preferences are reset.
Change-Id: Id0cfae46f93c10d89e441f272096a205ec518dd0
JNITest class is no longer actively used. This patch
removes the class (java and jni) files.
JNI interfaces and calls are extensively tested in
the art unit tests (art/tests) and in cts (see
CtsJniTestCases).
Change-Id: I62f7c72deb5d206fa3f545ae39a9cb9011110d0a
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
