We can use the new mechanism to ask the calling shell to open
a file in order to implement the rest of these commands, allowing
you to give the path to an apk to install. That API is thus
extended to allow you to open readable files, not just opening
file for writing.
Doing this however means we no longer can pass a file path to
AssetManager for the apk to parse, we only have an already open
fd for that. Extending AssetManager to allow adding apks from
fds is not that hard, however, since the underlying zip library
already supports this.
This main thing this changes is in AssetManager.cpp where we
retrieve the open zip file for a particular apk that has been
added. This used to look up the zip file by path every time
it was needed, but that won't work anymore now that we can have
things added by fd. Instead, we keep track of each opened zip
in the AssetManager, so we can just directly retrieve it from
the asset_path representing the item that was added. As a
side-effect, this means for normal paths we no longer need to
look up by name, but just have the opened zip file directly
accessible. (This is probably good, but it does mean that we
no longer run the logic of seeing if the zip file's timestamp
has changed and re-opening it if it has. We probably shouldn't
be relying on that for an active AssetManager anyway, and maybe
it is even good that we don't allow the zip file to change
under it?)
A follow-up change will finally remove the Pm.java implementation
and turn the pm "command" into a simple shell script that runs
cmd package.
Test: manual
Change-Id: Ie103e3bdaa5b706796cc329254f2638151a3924f
This change introduces minimal changes needed to support selection
of locales with BCP 47 numbering system specification. Two level
selection (Language/Region) schema remains, locales with numbering
systems appear in the region selection list and are displayed as
"region (numbering system)".
Bug: 18340949
Bug: 63754513
Test: manual, experimental UI for review.
Change-Id: I42691f3714c5e5c51fd8d96c034cc3a9f6be93dc
The only thing printed besides the stack elements is the classname `LogStackTrace`.
This is useless.
We can improve performance by only parceling around the StackTraceElement[] instead of serializing the whole Throwable.
testCrossBinderThreadViolation is currently ~3,700,000
Test: cts-tradefed run cts-dev --module CtsOsTestCases --test
android.os.cts.StrictModeTest
Bug: 68257982
Bug: 62458734
Bug: 68383527
timeThreadViolation_mean=374405
timeThreadViolation_median=372258
timeThreadViolation_min=367266
timeThreadViolation_standardDeviation=6998
timeCrossBinderThreadViolationNoStrictMode_mean=2331746
timeCrossBinderThreadViolationNoStrictMode_median=2337964
timeCrossBinderThreadViolationNoStrictMode_min=2226280
timeCrossBinderThreadViolationNoStrictMode_standardDeviation=64135
timeCrossBinderThreadViolation_mean=2484286
timeCrossBinderThreadViolation_median=2345391
timeCrossBinderThreadViolation_min=2331061
timeCrossBinderThreadViolation_standardDeviation=251332
timeVmViolationNoStrictMode_mean=2677281
timeVmViolationNoStrictMode_median=2733943
timeVmViolationNoStrictMode_min=2319806
timeVmViolationNoStrictMode_standardDeviation=295305
timeVmViolation_mean=3718122
timeVmViolation_median=3632176
timeVmViolation_min=3557980
timeVmViolation_standardDeviation=236624
timeThreadViolationNoStrictMode_mean=414257
timeThreadViolationNoStrictMode_median=414664
timeThreadViolationNoStrictMode_min=397317
timeThreadViolationNoStrictMode_standardDeviation=12954
Change-Id: If59812d71917aed08d557936ff7495d2f4ded23b
Fixes several issues with the way PendingIntents are being whitelisted
from background check with Notifications. Most visibly, this causes the
whitelisting not to work on Notifications that use the DecoratedContentViewStyle,
but there are some conditions where the whitelisting breaks for regular
notifications too.
- After a Notification is rebuilt with Notification.Builder, the set
of PendingIntents in the notification was not rebuilt.
This broke the whitelisting whenever a PendingIntent is added after
the Notification was already sent once. Workaround for broken platform
releases: always use a fresh Notification object, or clone before
sending.
- Fixes PendingIntent.writePendingIntentOrNullToParcel to invoke the
OnMarshalListener.
This broke whitelisting for any PendingIntents attached to custom
RemoteViews. Workaround for broken platform releases: Also attach
the PendingIntent to the Notification's extras.
- Changes RemoteViews to keep the parcel cookies that were present
during unparceling, such that they can be reapplied when it gets
cloned.
This broke whitelisting for any PendingIntents attached to a
DecoratedContentViewStyle *even if added to extras*. Workaround
for broken platform releases: none.
- Fixes Notification.whitelistToken mistakenly being static.
There's an unlikely race condition where the field could be
overriden with null by an incoming notification right as another
notification is sent out. Workaround for broken platform releases:
none.
Test: runtest -x core/tests/coretests/src/android/app/NotificationTest.java && runtest -x core/tests/coretests/src/android/widget/RemoteViewsTest.java
Bug: 68218899
Change-Id: I02e44040604a1d24422340611ae9e0332a611800
This removes all GlobalRef allocation as part of building BinderProxys.
Previously these were used to map IBinders to the corresponding
Java object, so the Java objects could be reused. We now keep
that mapping at the Java level.
This means we often need to call into Java to look up or allocate
a BinderProxy. But this replaces a prior call to Java to dereference
a WeakReference. The Java custom Java map-to-WeakReference data
structure is probably not terribly efficient, but the original
attachement mechanism did not seem to be either. And this
avoids potentially even more catastrophic issues when the number
of GlobalRefs approaches its limit.
We decrease GC triggering frequency from 200 to 1000 allocated
references. This now only applies to other kinds of JNI References
allocated by Binder.
I saw a maximum bucket size of 16 for the ProxyMap data structure
while briefly exercising a freshly booted device. That occurred
in system_server.
Bug: 65760710
Test: Built and booted master with some debugging output. Looks sane.
Change-Id: I322c4d8e9c8e198586d591580c2cdbb094906677
Adds new PROTO flag which requests services to dump sections in proto format. Modifies PriorityDumper helper class to parse proto arguments and set asProto flags. Registers WM and AM with proto dump supprt.
Bug: 67716082
Test: frameworks/base/services/tests/runtests.py -e class "com.android.server.utils.PriorityDumpTest"
Test: adb bugreport ~/tmp/bug.zip
Test: adb shell dumpsys window --proto
Test: adb shell dumpsys activity --proto
Change-Id: Icfc6857c8a9340110a43343734a27e48d0b5a229
Change the Java BinderProxy to only contain a single native pointer,
so that we can get by with a single NativeAllocationRegistry
registration. This adds some indirections and a new allocation. But it
marginally reduces the number of (expensive) JNI field lookups from
native code, and the extra allocation involves significantly less
overhead than registering each object twice. This also cleans up the
code a little by avoiding some explicit reference count adjustments.
Change BinderProxy Binder to use NativeAllocationRegistry instead of
finalize().
Change the mObject field in Binder to hold a non-reference-counted
but owning pointer to JavaBBinderHolder. Have JavaBBinderHolder no
longer inherit from RefBase.
Make it clear that neither Binder.mObject, not BinderProxy.mNativeData
can be null. Remove null checks.
Avoid checking for null returns from C++ new. It would throw
anyway, which would cause the process to abort.
Test: Booted master.
Bug: 65760710
Change-Id: I323d4bdc7e25f8c27b847b6fe2c073eac3f2efe5
Some violations have a separate string from the throwable. Prepending
the string to the throwable's message or using it as the message sets us
up for all violations to extend Throwable.
Bug: 62458734
Test: cts-tradefed run cts-dev --module CtsOsTestCases --test
android.os.cts.StrictModeTest
Change-Id: I6a97ee69a90fb975dc453ca37fe53ea78ebfe974
Also add appropriate @NonNull and @Nullable annotations.
Test: built
Change-Id: I22de48105ef685baf594cfc004dd3e27e2ba09e9
Merged-In: I22de48105ef685baf594cfc004dd3e27e2ba09e9
(cherry picked from commit 4cd650c008)
Everything is now moved out of the pm command except for
the various install commands. I am going to hold of on
those since they require doing some resolution with the
current implementations in the package manager to make
sure they match and behave identically to the implementations
currently in the pm command. But other than that, everything
in pm is now just redirecting over to "cmd package".
Also fix up some of the dumpsys output of a few other sevices
when asking to print the data for a particular package, so
the "pm dump" command gives a little more sane result.
Test: manual
Change-Id: I139e06e560203b72243d7eea9543c2240db0f8f8
statsd entries to clients. This change only includes changes on statds
side and does not include java library for clients to import. Java
library will be a separate change as it requires system api review.
Test: statsd, statsd_test
Change-Id: I306c6e9687801668cc0145b12d38406bfe634775
Currently StrictMode uses a string representation of the entire stack
trace throughout. Switching to passing Throwables will allow callback
consumers to traverse an array.
It does not regress the performance test added in ag/3083879.
Test: adb shell am instrument -w -e class android.os.StrictModeTest \
com.android.perftests.core/android.support.test.runner.AndroidJUnitRunner
timeThreadViolation_mean=332071
timeThreadViolation_median=328184
timeThreadViolation_min=311253
timeThreadViolation_standardDeviation=16106
timeCrossBinderThreadViolationNoStrictMode_mean=1843599
timeCrossBinderThreadViolationNoStrictMode_median=1824457
timeCrossBinderThreadViolationNoStrictMode_min=1810186
timeCrossBinderThreadViolationNoStrictMode_standardDeviation=43539
timeCrossBinderThreadViolation_mean=2300256
timeCrossBinderThreadViolation_median=2148796
timeCrossBinderThreadViolation_min=1792660
timeCrossBinderThreadViolation_standardDeviation=472271
timeVmViolationNoStrictMode_mean=27794864
timeVmViolationNoStrictMode_median=26617027
timeVmViolationNoStrictMode_min=23994153
timeVmViolationNoStrictMode_standardDeviation=3384362
timeVmViolation_mean=32878535
timeVmViolation_median=34775241
timeVmViolation_min=28373537
timeVmViolation_standardDeviation=3462046
timeThreadViolationNoStrictMode_mean=373863
timeThreadViolationNoStrictMode_median=388998
timeThreadViolationNoStrictMode_min=333664
timeThreadViolationNoStrictMode_standardDeviation=33219
Bug: 62458734
Change-Id: I6b3924be91f19654c502e0ec2f44cc07d6e86e3f
Test: cts-tradefed run cts-dev --module CtsOsTestCases --test
android.os.cts.StrictModeTest
getService: wait for service if it is declared in the manifest
tryGetService: only return if the service is immediately available
Bug: 67981006
Test: hidl_test_java
Change-Id: I4485b84f0fde98851cf5f64d198a8c5410795c8c
Previously, pulled data was returned as a string. We instead
return the data as an array of StatsLogEventWrapper, which encodes
using the binary-encoded format liblog uses. StatsD uses the same
parsing as for pushed events to convert these. This CL also fixes
the parsing of log_msg since the strings were previously emptied
before we had a chance to read the values.
Note that the cpp-aidl can't support List of Parcelable, so we
have to return the results as an array.
Test: Manual using the new command in StatsService to print results.
Also created a new unit-test by creating a dummy pull code of -1,
but this test is deleted since it required creating a fake output in
StatsCompanionService.
Change-Id: I1cfb9ea081a59292a60e934e8527adc40982ed80
This binder service is originally served by healthd.
To allow BatteryManager to continue to work, BatteryService
implements this binder service.
Test: BatteryManagerTest
Bug: 62229583
Change-Id: I9c97b3936546740c6d63060899fe50c5c4c957bd
