A side effect of CL topic r.android.com/q/topic:bug136256059_attempt2
was that the default MimeMap instance is now loaded eagerly (pre-fork)
regardless of whether any app process ends up using it, whereas
previously it was loaded lazily (post-fork) the first time an app
process used it.
This traded off CPU and memory use post-fork vs. pre-fork. Because it
isn't known / hasn't been proven whether and how many app processes
use that instance, the net CPU and memory impact is not known: if at
least one process makes use of a relevant API, the net impact will be
neutral or positive, or else negative.
Until this can be investigated and undergo system health review, this
CL topic changes the behavior back to post-fork lazy loading of the
default MimeMap instance.
Bug: 142019040
Test: Treehugger
Change-Id: I2a3f244240c51e7ada1f41a8abadb946ebcab40b
Another CL in this topic moves libcore.net.MimeMap to package
libcore.content.type. This CL updates associated references.
Bug: 136256059
Bug: 124232146
Test: Treehugger
Test: CtsMimeMapTestCases
Exempt-From-Owner-Approval: move affecting imports only
Change-Id: I30aac8b28a1740180ea01834a2bb66b61cb255d4
The java.io.FileDescriptor object has a poor definition of ownership,
which can result in obscure use-after-close bugs. Instead, APIs should
return or accept ParcelFileDescriptor instances.
Bug: 130209137
Test: manual
Change-Id: Ifb3dd53dc138ec47f416f2d4b46c4668bc8ee1d8
The zygote handles requests by polling on its sockets, and then handling
one request for each active socket. However, it does so by reading from
a socket via a BufferedReader, which means that if multiple requests are
written into the socket before the zygote gets a chance to read them,
the zygote reads multiple requests into its BufferedReader, it handles
one request, and then never responds to the request that's buffered,
leaving its client stuck waiting for a response that will never happen.
For most requests, this can't happen, because the client will wait for a
response to be sent from the zygote before sending another request, but
this isn't true for --boot-completed until this patch.
Bug: http://b/141767463
Test: forrest runs of apct/text/text_native_test-cloud-tf
Change-Id: I8b7a80abfd9443d98f8cf5aedb7669b82c0cb84a
Needed for scoped storage (to be used from MediaProvider).
IsChangeEnabled returns true if there are no installed packages for the
required UID, or if the change is enabled for ALL of the installed
packages associated with the provided UID.
Bug: 138275545
Test: Test app
Change-Id: I6785f57e4fcfb92ed7529f4da0a6db6ffe8b3ad4
There isn't much users can do to get app developers to care anyway, so
leaving this on just for apps with debuggable="true" should be
sufficient.
Bug: http://b/141754375
Test: treehugger
Change-Id: I3a796f9c4b9358fce499649c3f289e956ee9a97a
* changes:
MimeMapImpl.createDefaultInstance() -> DefaultMimeMapFactory.create().
Make MimeMap final and introduce MimeMap.Builder.
Move default MimeMap implementation to frameworks.
The class no longer implements MimeMap, so the name MimeMapImpl
no longer made sense.
Test: Treehugger
Bug: 136256059
Change-Id: I2cbc70a7769232b704a9bdfde2def832c1e292b8
This is the second attempt to submit this CL. The first attempt
regressed on app startup because RuntimeInit installed the
custom MimeMap from commonInit() which runs post-fork of the zygote,
but that was fixed by installing it pre-fork.
This CL topic moves the default MimeMap implementation to frameworks.
Libcore starts with a minimal implementation sufficient to pass
CtsLibcoreTestCases, but frameworks can inject the real implementation.
Before this CL topic, the data files and logic (MimeMapImpl) were part of
core-*.jar on device; after this CL, they instead live in framework.jar.
Tests from MimeMapTest that check behavior of that default
implementation also move to a non-libcore CTS test.
Planned work for follow-up CL:
1. Make CTS more opinionated, with a plan to assert that all of
the default mappings are present. How exactly the expectated
mapping will be bundled in CTS is still TBD.
2. Add a vendor.mime.types file (defaults to empty) where vendors
can add additional mappings; I plan to make it such that mappings
in that file are parsed last but never override any earlier
mappings, as if each mime type / file extension was prefixed
with '?'.
3. Perhaps enforce that public APIs android.webkit.MimeTypeMap
and java.net.URLConnection.getFileNameMap() behave consistently
with MimeMap.getDefault().
Test: atest CtsLibcoreTestCases
Test: atest CtsMimeMapTestCases
Test: Checked that CtsLibcoreTestCases still passes on a build that
is missing the MimeMap.setDefault() call from RuntimeInit.java.
Test: Checked that app startup time does not regress as part of this
CL topic - see http://b/136256059#comment17
Bug: 136256059
Change-Id: I716914bf1a7e6205e539f0551f010615dacb17a8
Limit 1 log per app launch as the statd logs as this is spamming logs.
Consider increasing in the future to once every x minutes/seconds if
needed.
Bug: 138374585
Bug: 141714588
Test: flash device
Change-Id: I3ed696fb557527d807d03aecc64c0207d7b93f08
Until recently, I and apparently some others were under the assumption
that RuntimeInit.commonInit() runs before the Zygote fork. Actually, it
does not.
This CL introduces a method ZygoteInit.preForkInit() which runs before
the Zygote fork. For now, only enableDdms() moves into it and can become
private. This should not alter behavior since enableDdms() is called
from the same places as before, and because enableDdms() (now private)
was already not part of any API surface.
The CL also removes the qualifier "final" from the (static) method
enableDdms(), because it is redundant.
Note: This CL was uploaded with --no-verify because of preexisting
import ordering issues in RuntimeInit.java
Test: Treehugger
Change-Id: I8f637e160a2d7810feb43b6a43ec7d628af18fb8
Only log once per change-package-state(resets every app launch if used
from within the app process).
Next: reset every app launch for server usage as well.
Test: using the test app.
Bug: 138374585
Change-Id: I5587f7138cf2cd8d144e88cf294e65c14bb32bfb
The APIs behave the same as the AppInfo APIs, and returns the change is
enabled if there is no installed package with the provided name.
Test: flashed device, used the test app, and made the API use the new
per-package API.
Bug: 138275545
Change-Id: Ic925751dddc6c2e0996fe195a208f5c689554839
Instead of just relying on the regular iteration through the system
services inside dumpstate, add another API to IIncidentManager
dedicated for dumpstate.
- It is only callable by dumpstate() (check the calling uid)
- It has the same behavior as the current call inside dump()
Advantages:
- More explicit function name, right next to takeIncidentReport will
make it easier to keep them in sync.
- Nobody else can call it, make security easier.
- If dumpstate calls it explicitly, it can skip the 10 second timeout
- The regular dump() call should provide debugging data about
incidentd itself, for example timestamps for the most recent N
incident reports taken and the current state of the work directory,
allowing us to debug incidentd itself.
Bug: 137493082
Test: Manually trigger a bug report, and verify
/proto/incident_log.proto in the zip file.
Change-Id: I19139c765b53ede63d3beb3ea3ac40ada1aba42d
Merged-In: I19139c765b53ede63d3beb3ea3ac40ada1aba42d
This commit is mainly from I7a6a30bf8e8db9f2738594d187bb9148f138b8da, so
test cases and features are mostly same.
We change product_services partition name to "system_ext" because this
partition's purpose changes.
- installing a RRO package for framework from /system_ext/overlay
- installing apps from /system_ext/app
- installing priv-apps from /system_ext/priv-app
- installing permissions from
/system_ext/etc/[default-permissions|permissions|sysconfig]
Bug: 134359158
Test: `mma` under frameworks/base/tests/[libs|privapp]-permissions
adb sync && adb reboot
adb shell cmd package list libraries
=> confirmed com.android.test.libs.system_ext library
adb shell cmd package dump \
com.android.framework.permission.privapp.tests.system_ext
=> confirmed that the package is a priv-app
Change-Id: Ibbccbba64156a7bc464ffb3785fb8fe69ebb973c
Merged-In: Ibbccbba64156a7bc464ffb3785fb8fe69ebb973c
(cherry picked from commit 9ec059ac1d)
Optimizes the logic that ensures the default randomized MAC is not
returned.
Bug: 137796328
Test: atest MacAddressTest
Change-Id: Ie95d7a020bfac8850b8a67e4d396de77db22e1db
- Allow recents component to enable/disable layer tracing
- Expose flickerlib classes for use with sysui/launcher tests
- Allow trace files to be moved to a path that the client can read
- Ensure layers are flattened with depth traversal to encode ordering
Bug: 140244969
Test: atest FlickerTests
Change-Id: I7af5699ff5b8a4bc62c1a8105c67b31bc45a2236
Merged-In: Ia0934ec7c2b9484fa6c85f5aa8d9b2e5e6f7dc0f
Add a new atom and log from both the app process API and the system server API
Bug: 136794938
Bug: 138378110
Test: statsd_testdrive 228
Change-Id: I80f07d0beb30c779c4bce70bebf2bb4ab22f6bfe
Merged-In: I80f07d0beb30c779c4bce70bebf2bb4ab22f6bfe
This change updates how AudioService is updated of changes to Hdmi Cec
status (enable/disable) and availablity.
Bug: 138956107
Bug: 138373017
Test: Android TV STB: make; flashall;Volume -/+; HDMI control enable/disable.
Change-Id: Iaf83a45206be076858e13d113ba772ed5c59ef60
Merged-In: Iaf83a45206be076858e13d113ba772ed5c59ef60