Activity aliases do not pick up values in the PackageParser. The
actual values should come from the target activity instead.
Also ActivityInfo now propagates maxRecents in copy constructor
and across Binder calls (via parcelling).
Fixes bug 17391328.
Change-Id: I35d248032eca7557528c9d499b3b38f27c713d09
View methods that previously accepted a TypedArray to initialize
parameters parsed from xml cannot be used correctly by apps. The
TypedArray passed must always be obtained from a context using the
filter array com.android.internal.R.styleable.View, which is not
visible to the SDK.
A previous change already made this safe for existing apps already
using it so that they don't crash, this change removes these methods
from the SDK entirely.
Change-Id: I62099087ad6fd5bf8363e863b04fd0434b8cdfca
The major change is that consent is now "sticky" and lasts until the
user explicitly disables the VPN connection.
Bug: 17474362
Change-Id: Id4e7807e635bbfc7645741135209d46763e280f9
When Android processes fork from Zygote, we rewrite the command line
with a new name, eg. "system_server". When we do this, we should
fill the entire block with zeros to remove corrupted argument
information that may otherwise remain in the /proc/<pid>/cmdline buffer
and be seen in tools and stack dumps.
Fixed an issue where VM options could be overwritten after setting
the nice name if the name was too long.
Bug: 17474152
Change-Id: Ie6cf9ed7752a04300a340e26cd6812bb35c59e1b
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
The print preview UI owns and drives the lifecycle of several objects.
These objects were torn down too late resulting in an attempt to use
the activity as a context when it was no longer valid and service unbind
resulting in causing a crash.
Fixed a bug where if the back button is pressed mutiple times when
the print UI is being initialized a crash occurs.
bug:17454041
Change-Id: Ic1455b467586f0ad65f907e2160ec5cfb2d17d05
Ran out of file descriptors and got a null file list. This
checks for null file list.
Fixes bug 17461213.
Change-Id: Ia6d49d0bdb6da98623b76d2b87cd09bc0afa1f27
+ 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
