When an app is debuggable, check whether a script called "wrap.sh" exists
in the app's native library directory. If so, start the app using the
invoke-with functionality over the script. Weaken the invoke-with check
on the zygote side to allow the functionality for debuggable apps.
The goal of the functionality is to make malloc debug, strace and other
similar tools available for NDK based application developers.
Bug: 33668201
Test: manual - debug malloc can be enabled using the new feature
Change-Id: Ia4bec0854cf4dc08446f1671494200f54ef366ee
Add "--invoke-with" to the zygote connection protocol. It was
already understood as an argument by the zygote.
Bug: 33668201
Test: m
Change-Id: I59095f2ac542aadff78a7ff1dded86cf5f192707
There are a few major pieces here:
incidentd
---------
This daemon (started by init) runs and accepts incoming requests to take
incident reports. When prompted, it calls into various system services
and fills in an IncidentProto data structure, and then writes the report
into dropbox.
The next steps for incidentd:
- Security review of SELinux policies. These will be a subset of
the dumpstate permissions. Until this is done, incidentd is
not started at boot time.
incident
--------
This shell command calls into incidentd, and can initiate an incident
report and either capture the output or leave for dropbox.
incident_report
---------------
This host side tool can call adb shell with the correct parameters
and also format the incident report as text. This formatting code
was left of the device on purpose. Right now it's pretty small, but
as the number of fields increases, the metadata and code to do the
formatting will start to grow.
The incident_report command also contains a workaround to let it
work before incidentd is turned on by default. Right now, it is
implemented to call adb shell dumpsys <service> --proto directly,
whereas in the future it will go through the full incidentd flow.
incident_section_gen
--------------------
A build-time tool that generates a stripped down set of information
about the fields that are available.
libincident
-----------
This library contains the code to connect to incidentd, and the
meta proto definitions that are used by the framework protos.
The basics are here now, but they are not fully fleshed out yet.
The privacy.proto file contains annotations that can go in the
proto file that we will later use to filter which fields are
uploaded, and which are used by local sources. For example, a
device in a test lab is safe to upload much much more information
than a real user. These will share the same mechanism, but the
user's output will be filtered according to these annotations.
frameworks/core/proto
---------------------
These .proto files contain the definitions of the system's
output. There is one master android.os.IncidentProto file that
is the top level of an incident report, but some other services
(notification, fingerprint, batterystats, etc) will have others
that are used directly by the logging mechanism.
Other files which are shared by several of the services also go
here, such as ComponentName, Locale, Configuration, etc. There
will be many more.
There is also a first iplementation of a dump method handling
--proto in the fingerprint service.
IncidentManager
---------------
The java API to trigger an incident report.
Test: Not written yet
Change-Id: I59568b115ac7fcf73af70c946c95752bf33ae67f
It looks like one operation was done out of order and some of the times used in
the calculations were leading to incorrect results.
BUG: 31023263
Test: bit FrameworksCoreTests:com.android.internal.os.BatteryStatsDurationTimerTest
Change-Id: I417cc28c5a55748067b6c7f682a66fe3dbc09f09
This is needed for unbundling of OobConfig app.
Test: gts-tradefed run gts -m GtsGmscoreHostTestCases --test com.google.android.gts.devicepolicy.DeviceOwnerUserRestrictionTest#testDisallowOemUnlock_canSetWithSystemApi
Test: gts-tradefed run gts -m GtsGmscoreHostTestCases --test com.google.android.gts.devicepolicy.DeviceOwnerUserRestrictionTest#testDisallowOemUnlock_doCannotSet
BUG: 32974379
Change-Id: I7710df96006821a5d0eddfe0b411dd3efa0e10f0
Now that installd is throwing both SecurityException and
IllegalArgumentException, it's time that we turned all these
into InstallerException.
Also extend ServiceSpecificException to include the contained
errorCode value when printing.
Test: builds, boots, apps install/uninstall fine
Bug: 13758960, 30944031
Change-Id: Ic9c1e99ae87f4442402ef528bf352c7978572c85
UserManager.isUserUnlocked/isUserRunning/isUserUnlockingOrUnlocked now
return state from UMS.mUserStates that is pushed from ActivityManager.
Test: create managed profile using TestDPC and check Launcher3
Test: manually create unstarted managed profile and check launchers
Bug: 33232933
Change-Id: I6b619ba1880188eabdd6e3e4cc7eb60d3a22a977
When Binder calls are nested, we can quickly end up with a snowball
of stacktraces that can cause the original transaction to fail. This
CL makes two specific changes to alleviate this pressure:
-- Consider a nested Binder call from PID A -> B -> C. If both B and
C encounter dozens of StrictMode violations, then gatheredViolations
in B will end up with 10 ViolationInfo (5 from B and 5 from C). This
problem only grows with each successive nested call. To solve this,
always limit ourselves to only ever write out 3 ViolationInfo from
any given process.
-- CrashInfo already nicely truncates any large stack traces to 20kB,
but readAndHandleBinderCallViolations() blindly appends the entire
local trace, and never considers truncating again. Similar to the
first problem above, nested calls can quickly cause the stackTrace
value to explode in size. To solve this, we always re-truncate the
stackTrace value after appending our local stack.
Also fix some NPE bugs when missing crashInfo.
(cherry-picked from commit 58f27b5033)
Test: builds, boots
Bug: 32575987
Change-Id: Ie8373ca277296f920f2b1c564d419c702a8ee0f2
When Binder calls are nested, we can quickly end up with a snowball
of stacktraces that can cause the original transaction to fail. This
CL makes two specific changes to alleviate this pressure:
-- Consider a nested Binder call from PID A -> B -> C. If both B and
C encounter dozens of StrictMode violations, then gatheredViolations
in B will end up with 10 ViolationInfo (5 from B and 5 from C). This
problem only grows with each successive nested call. To solve this,
always limit ourselves to only ever write out 3 ViolationInfo from
any given process.
-- CrashInfo already nicely truncates any large stack traces to 20kB,
but readAndHandleBinderCallViolations() blindly appends the entire
local trace, and never considers truncating again. Similar to the
first problem above, nested calls can quickly cause the stackTrace
value to explode in size. To solve this, we always re-truncate the
stackTrace value after appending our local stack.
Also fix some NPE bugs when missing crashInfo.
Test: builds, boots
Bug: 32575987
Change-Id: Ie8373ca277296f920f2b1c564d419c702a8ee0f2
Only the device owner will be able to set the restriction
and the restriction will prevent usage of Bluetooth on the
entire device - i.e. in all the users.
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.UserRestrictionsTest
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.DeviceOwnerTest#testBluetoothRestriction
Bug: 32895300
Change-Id: I2875cf178cb16eca1965d0ba965d1cd3d8db2ad5
Only the device owner will be able to set the restriction
and the restriction will prevent usage of Bluetooth on the
entire device - i.e. in all the users.
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.UserRestrictionsTest
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.DeviceOwnerTest#testBluetoothRestriction
Bug: 32895300
Merged-In: I2875cf178cb16eca1965d0ba965d1cd3d8db2ad5
Change-Id: I2875cf178cb16eca1965d0ba965d1cd3d8db2ad5
UserManager.isUserUnlocked/isUserRunning now returns state from
UMS.mUserStates that is pushed from ActivityManager.
Test: manual
Bug: 33232933
Bug: 28957340
Change-Id: Ic5f56d7d577bc336acd2bf44fab7f74feac4f7b3
Follows the same marshalling scheme as other list types, such
as lists of Strings etc.
Bug: 30792387
Test: ParcelTest
Change-Id: I2003f4fcf4de5a1bee060f3c2723cfb155105b14
Developers regularly put content:// Uris into Intents, but they can
easily forget to add FLAG_GRANT_READ_URI_PERMISSION to actually
extend a permission grant to the receiving app.
Also fix NPE when path is missing.
Test: builds, boots, common actions work without triggering
Bug: 32447617, 31900890
Change-Id: Ic6054b1d73de50967cf7fe66abc293c60a41b97e
The CL adds FuseAppLoop internal class to the framework. It parses FUSE commands
from the proxy in the system service and invokes a callback provided by
application.
Bug: 29970149
Test: None, will be tested with CTS for StorageManager#openProxyFileDescriptor.
Change-Id: I10b2add4c2743fb91eae3cb194f55843a74fb668
Support a system property on debugable builds to
override the max number of managed profiles to
allow easier dogfooding of multiple profiles.
Support 3 different badge colours for managed profiles.
Bug: 30473760
Test: runtest -c com.android.server.pm.UserManagerServiceCreateProfileTest frameworks-services
Test: runtest -c com.android.server.pm.UserManagerServiceUserInfoTest frameworks-services
Test: manual - attempting to create 2 profiles with adb fails, passes once I set the property.
Change-Id: Ie7fb19048a04a01572666f229283152254d0ffc3
We know they will be ASCII, so use String.getBytes(US-ASCII) which is
much faster than creating a new ICU based CharsetEncoder for UTF-8 every time
we write one of these files (there will be a lot of them).
Test: make + manual.
Change-Id: I8eb62862ea1083e194d3f23ac68bb40aaae5efd5
