Application may use many threads to load data from provider.
If the target provider needs to start process, each access
will occupy one binder thread of system server until the
provider process started and published.
Sometimes application uses more than 16 threads to access
the same provider, and the provider process needs a little
long time to start, then all binder threads of system server
are waiting. But when the provider is ready, it is unable to
publish to notify those waiting threads because no availabe
binder thread to use. And device will become almost hang.
Improvement:
If there is already a thread acquiring provider, let other threads
(which try to acquire the same provider) wait the result of the
first one. That reduces IPC to save binder thread of system server.
Remove calling removeContentProvider in installProvider because
we have ensured only get one provider holder for the same provider,
the original race that gets a new useless holder will not happen.
Change-Id: I521f2603db8ced56912f5dc54342a70451e68381
The initial purpose of the NetworkSecurityPolicy class is to provide a
way for network libraries to check whether cleartext network traffic
(e.g., HTTP, WebSockets, XMPP, IMAP, SMTP) should be blocked from this
process.
The policy is set declaratively by the app developer in the app's
manifest and can be queried from ApplicationInfo.flags. Unfortunately,
several network stacks (bundled and unbundled) do not have a reference
to ApplicationInfo or Context.
Alternatives:
* Keep this API hidden (and thus potentially move it from framework to
libcore), thus precluding unbundled HTTP stacks from using the API.
* Introduce a new java.lang.System property instead of this API.
However, such properties are a mess and not as powerful/extensible
as a public class.
Bug: 19215516
Change-Id: If22056a74d257bf1d805ebb4fc284240b3d338f1
Using a static Pattern in ActivityThread prevents compile-time
initialization of ActivityThread and GestureDetector, which depends
on the former.
It is also not efficient, as String.split has a fast path for simple
splits.
Bug: 19542228
Change-Id: I5bb843c08c81e0d259bb8afafa87a8467bb1730e
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
