Address more cases where calls to getPanelState may cause a crash when the
options panel is disabled on a platform.
Bug: 19178531
Bug: 18780696
Change-Id: Ib72bb8483e636181788ed3919c4cb9e99a94b7b1
- Added a config entry in velues-television to disable the options panel
feature for TVs.
- Fixed parts of the code in PhoneWindow that assumed this feature is supposed
to always be available, which was causing exceptions when it was turned off.
Bug: 18780696
Change-Id: I923bd4b5019d634e5352a6e893005133edb475f6
Bug 19105460
When an Activity Transition was receiving an exit call
immediately after the enter, the transition for the enter
was still in progress. TransitionManager does not allow
multiple transitions to work at once, so the enter transition
would run, but the exit did not. This CL detects when the
enter transition is still pending and tells the
ActivityTransitionState to delay one frame so that the
enter can finish its required work prior to starting the
exit transition.
Change-Id: I1b40f1e41d61a67da3fd672419ea321e7d0496da
Reason: Executing service com.google.android.syncadapters.contacts
/.SyncHighResPhotoIntentService
Make the code more robust when destroying services, so that if
the nesting count gets out of sync we don't just hang.
Change-Id: If117d5ef242e7c148fd9576bd89a1a092583d6ad
Introduces new module that provides network-related features for
the StrictMode developer API. The first feature offers to detect
sockets sending data not wrapped inside a layer of SSL/TLS
encryption.
When a developer enables, we ask netd to watch all outgoing traffic
from our UID, and penalize us accordingly if cleartext sockets are
detected. When enabled, netd captures the offending packet and
passes it back to the owning process to aid investigations. When
death penalty is requested, all future traffic on the socket is
blocked, which usually results in a useful stacktrace before the
app is actually killed.
Bug: 18335678
Change-Id: I3adbc974efd8d3766b4b1a23257563bb82d53c29
We'd observed a bug in which an unchanged file was nevertheless
being redundantly transmitted for backup on every backup pass.
The underlying issue turns out to have been the FileBackupHelper
base implementation's logic for diffing the prior-state file
set against the current state, in the case when there had been
deletions of prior files. In addition, there was also a
parallel bug in which file checksums were not calculated
properly in some cases, leading to at least one additional
redundant backup of the file in question.
Bug 18694053
Change-Id: Ie0dec06486b5fef4624561737019569c85d6b2a0
Explain why FLAG_MANAGED_CAN_ACCESS_PARENT and FLAG_PARENT_CAN_ACCESS_MANAGED
have these names.
Also do not mention the disambiguation list since there is not always a
disambiguation list shown when resolving cross-profile intent filters.
BUG:18962528
Change-Id: Ibbb9505dcab7cf17d87435eff2cef3e745e95209
If the manifest doesn't specify large heaps, we now call
VMRuntime.clampGrowthLimit to release heap virtual address space
which won't ever get used.
Bug: 18387825
Bug: 17131630
Change-Id: I61fdcd70c70234256637eeebefe3abb22b91095d
Fall through to below logic and return null instead of crashing the
entire app. We already tell developers the value may be null.
Bug: 17781998
Change-Id: I05dce90ae6bc547d74f8c16d30b3dc7888a937fe
We now cleanly handle the case of the transport blacklisting specific
packages from key/value backup. Previously we would halt the entire
backup pass and reschedule if the transport returned any error from
performBackup(pkg). Now, we recognize the TRANSPORT_PACKAGE_REJECTED
result from that invocation, and properly drop that package's work
but proceed with running the rest of the backup queue as expected.
Bug 18694053
Change-Id: Id0dd6d59492bdea9f970540d776f37db0cc5d99c
Fixes a regression where Builder.setIcon(Drawable) would get overridden
even when Builder.setIcon(int) had never been called and was still 0.
Fixes attribute id to respect all valid resource IDs (e.g. non-zero).
Updates documentation to reflect the long-standing override behavior.
BUG: 18904762
Change-Id: I905703993a59910555d5a858e0aaecab63221a02
Symptom:
Assume a foreground broadcast FG and a background BG.
If a recevier registers both FG and BG. When sending
BG and FG to the receiver, and the receiver BG receiver
completes first, its finishReceiver will trigger next FG
receiver rather than BG, and also deliver wrong result
code/data to the next.
More detail and sample:
https://code.google.com/p/android/issues/detail?id=92917
Root cause:
Due to BroadcastQueue:getMatchingOrderedReceiver will match
by receiver(IBinder), so the caller ActivityManagerService:
broadcastRecordForReceiverLocked will always match the first
queue(fg) if a receiver is both receiving fg and bg.
Solution:
Add a parameter flags to finishReceiver, then server side
could know the finished receiver should belong to which queue.
Another general solution but with bigger scope:
I60dce4a48e20c1002a61a979e4d78b9b0a8b94a0
Change-Id: I913ca6f101ac8ec6c7a8e42754e6781f80247b7f
This is a regression where we changed the source view for the transition
to dummy view, but since it was not yet attached, it could not get the
handler implicitly to post the onAnimationCompleted callback. This CL
modifies these ActivityOption transitions to also take an explicit
handler to process the callback on.
Bug: 18784289
Change-Id: I73f745c33b9f8aed91f8d9cd975f37cf7e4128f1
