These APIs were added because we thought we needed them to provide
seamless transition from one server backend to another using local IP
addresses to distinguish between the backends. I.e., connections whose
local IP address was old would be routed to the old backend; connections
whose local IP address was new would be routed to the new backend.
It turns out that's not needed. VpnService already supports seamless
re-establishment, so VPNs just need to call establish() again with a
different IP address. I've verified with a custom VPN app that this
works, and can distinguish traffic based on the old and new addresses.
Nobody is using these APIs at the moment, so we could even consider
removing them altogether, but I prefer just hiding them, just in case.
Bug: 15409819
Change-Id: I30949926a0f859c9d839981ccbc5d8e1e535a3a5
Before fix, test assumed that it was already connected to wifi so remove
these assertions. Also, since association test may be used against
access points with no outside connectivity, remove the ping test to
8.8.8.8 at the end.
Change-Id: I3d4f3d752b72028f642da9f8e9adda4ad18a6a56
+ Add constants GATEWAY_PROVIDER_PACKAGE and GATEWAY_ORIGINAL_ADDRESS
- Remove those corresponding constants from private packages
+ Modify clearAccounts() so it no longer takes an argument.
Bug: 17329632
Change-Id: I3794efe5ad1fafe6e22f4a59146859a96a385ed1
...rather than overwriting the existing wallpaper bitmap file "in
place." If the new bitmap is smaller than the previous one, we wind
up with the previous image's contents as spurious trailing file
contents. Also, it means that if any wallpaper image is particularly
large on disk, then we'll forever be backing up that high-water-mark
amount of data every time the wallpaper is changed.
The fix is to open the "write the new bitmap to disk" fd with
MODE_TRUNCATE.
Bug 17285333
Change-Id: I3d8708d72e316834b7ecec20386153a703efddd9
Also changes intent returning method from get to create. Both changes
are in response to API council feedback.
Bug: 17389882
Change-Id: I3b57e3fc202148e3bbb24ac61229f04e8b4ac41e
The old version of the code wanted to just check to make sure
that the slot/phone id is greater than INVALID_SLOT_ID or
INVALID_PHONE_ID that are both currently defined to be -1000. The
changes are made for 2 reasons. First, INVALID_SLOT_ID and/or
INVALID_PHONE_ID might not always be defined to be a negative value
so there is a big assumption. Secondly, anything greater than
-1000 allows other negative values to be considered valid ids.
Bug: 17243556
Change-Id: I2bbfcc2cfd2d7c4772dfb9c50af2dc88c0f315e2
An earlier fix in L disabled hw acceleration for the starting window
after the system process became hw accelerated. This was done to preserve
the old behavior of the starting window having some default behavior
(in particular, being filled with a default color). However, this ends up
being a memory and performance problem on some platforms (memory because
some platforms have backing store for software surfaces, performance
because it takes far longer to create a screen-size software surface than
a hardware surface).
The fix is to allow the starting window to inherit the hw acceleration
behavior of its process, and to detect when we are drawing the contents
of that starting window and to fill it with a default color (black).
Issue #17443449 use hardware rendering for app preview window
Change-Id: I8be8111d9e38c51fbbc07185acca065815ce26dc
Bug 17006497
Window content transitions were being enabled by default in
the Material Theme so that Activity Transitions could be
enabled by default. Unfortunately, this gave the effect that
many applications did not want -- the default transition between
window content is a fade out/in. Here, a new attribute is
added: windowActivityTransitions that is enabled by default
in the Material theme and windowContentTransitions is disabled
by default in all themes.
Change-Id: Iab453d608f00a48ff7ab7f09ce84b52cf5f20294
On the minimal framework start, don't mark ro.runtime.firstboot, allowing
the real framework to properly create the dropbox files in the real /data
Bug: 17450632
Change-Id: Ic53b3471b44e69f3eea7e3f3de18e789f51192bc
Instead of pulsing every 30 seconds to mimic the LED, use
a function that pulses more frequently for new notifications,
decaying to a slower pulse, and eventually stopping.
Specifically, the step function for the interval is:
- 10 seconds for the first minute
- then 30 seconds until the five minute mark
- then 60 seconds until the 30 minute mark
- then no pulsing at all
- Since we pulse more frequently on new notifications, remove
the "multi-pulse" concept.
- Move all doze-related duration parameters to a new helper,
backed by config, overridable by sysprops, include in dump.
- Wake up from dozing when hitting volume keys during a pulse.
-
Bug:17393939
Change-Id: Ica86f08b25c738338fced165c77faf3dfccd0343
Bug 17452965
A single point Path (move-to only) was not returning any
verbs in the verb list. This forces an approximation for
single move-to and empty paths by giving the same value
for fraction 0 and fraction 1.
Change-Id: Icb1b932d730457680cf422377a83fe669f0a7687
