While the tracker session ends abnormaly, we should also remove the task
which is kept by InteractionJankMonitor, or a memory leak happens.
Bug: 184651704
Test: atest FrameworksCoreTests:InteractionJankMonitorTest
Test: atest FrameworksCoreTests:FrameTrackerTest
Change-Id: I56f7759ef39d34cedc795042d3210d9be375cf77
Pushing these as a metric will come in a future change.
Test: unit tests
Bug: 180584913
Change-Id: I8a123f7aed7c0ce416814372f2287b04a8a04ac0
Merged-In: I8a123f7aed7c0ce416814372f2287b04a8a04ac0
(cherry picked from commit 8d0ecde2b8)
Use the SyncNotedAppOp when collecting self/sync ops in AppOpsManager.
Also adds "mode" to SyncNotedAppOp
Fixes: 184111263
Test: Atest AppOpsServiceTest
Change-Id: Ia20c7054d06e241cbe017a641d728e11c7eccd06
Bug: 184256183
Prevents NullPointerException when there are no children in the
RecyclerView while a fling occurs.
Test: Ran share sheet
Change-Id: I6aa5a4622c8afa792ca5e3f4c8fffb9ec92128d9
The BackgroundBlurDrawable is linked to a specific ViewRootImpl.
When the view is detached and re-attached, the ViewRootImpl changes, so
we need to reinitialize the background blur drawable inside DecorView.
This CL properly handles onDetachedFromWindow in DecorView.
Bug: 177523043
Test: m && atest BlurAggregatorTest
Change-Id: I2e25a2f85bdf95c151fd01dc794a6bc4b16c03b1
Keep the constants are only used by framework in TrafficStatsConstants
and move the others to NetworkStackConstants which is in libs/net.
Bug: 182349970
Test: FrameworksNetTests
NetworkStackTests
TetheringTests
Change-Id: Ib667c115e5f1e01237d88b77bba753363da309cc
Merged-In: Ib667c115e5f1e01237d88b77bba753363da309cc
This method will be used for testing and visualization purposes.
Bug: 184207674
Test: atest FrameworksCoreTests:com.android.internal.os.BatteryStatsTests
Change-Id: Id28ba4cbb8f27774f36248678f93ec187bc022b3
This reverts commit 39db76b534.
Reason for revert: Eng-prod no longer requires this patch
Bug: 169376495
Change-Id: I93be09f03745734d65190a5a39f79d90c0150652
Handle onConfigurationChanged() in order to prevent restarting
InputMethodService everytime. We introduce a new API attribute
"configChanges" in InputMethod(attrs.xml) which when declared
by IME, will be responsible for handling mentioned
configuration changes.
This CL re-introduces [1] with fix: Use new Configuration instance for
IMS#mLastKnownConfig and also handle followup comments.
[1] Ib94fddadb0dae648cf73a4c1642e51edebd19f50
Note: this change has no impact for devices not using DisplayAreas.
Bug: 167948419
Test: atest InputMethodServiceTest
Manually:
1. Patch Ie91e7a8e06b80864ef9409031e8543858552d70d to use dual
display area.
2. Open applications with editors on both display areas.
3. Attach a debug point for IMS#onConfigurationChanged().
4. Make sure IMS#resetStateForNewConfiguration() is not called
when IME moves between these two identical DisplayAreas
Also verify that bug 182604598 don't happen.
Change-Id: I43b6b80cdb35410554412ee1d3b0917ee3198272
Notify device's cell location when ACTION_USER_SWITCHED even though no
changes.
And 1st arg of notifyCellLocationForSubscriber() shall be subId instead.
Bug: 177495399
Test: atest TelephonyRegistryTest
Signed-off-by: Taesu Lee <taesu82.lee@samsung.com>
Merged-In: I6761c4bb500da1748119f9917663dae0307ab437
Change-Id: I6761c4bb500da1748119f9917663dae0307ab437
In order to detect memory regressions caused by improper handling of
dma-buf buffers we need to measure how this memory is used.
This change:
- Introduces DmabufInfoReader which wraps libmeminfo and provides
per-process DMA-BUF stats.
- Specifically, measures buffers mapped to the process address space
(from /proc/pid/maps). This is supported on all devices.
- For devices running 5.4+ (where the system processes can query fdinfo)
also measures the total retained memory (either by mmap or an open fd).
- Introduces a statsd atom that collects this for all running managed
processes. Non-managed processes will also hold dmabufs, but the
likelihood of them causing issues (post-launch) is smaller so I am
trading them off for cheaper collection (if indeed we encounter such
problems, they will definitely be caught by the total dmabuf counters).
Test: manual
Bug: 183708249
Change-Id: I5e0ef58ac1a66ebe2d280c5733de46ba84f75a46
This API is appropriately called "ViewRoot". So far we just expose
an API surface to reparent SurfaceControl to the ViewRoot (but without
exposing the ViewRoot's SurfaceControl, to encourage developers not
to shoot themselves in the foot) and to synchronize with the drawing
of the ViewRoot SurfaceControl.
Bug: 173463039
Test: ViewRootSyncTests
Change-Id: I8ce0ed4b3efe50cdb3b71ae0f05ce25438d42368
Since this is intended to be used by PhoneWindowManager,
this patch also hoists these internal constants out of
SystemUI and into com.android.internal.app.AssistUtils.
Adds the new UiEvent ASSISTANT_INVOCATION_POWER_LONG_PRESS
for future use by calling code.
This patch also fixes an inconsistency in the existing
constant names (internally to these files).
Fixes: 181601214
Test: atest SystemUITests
Change-Id: Ida860d78ef490e0dc119b37287c6ecdff5b9c0de
When an app is proxying access to runtime permission protected
data it needs to check whether the calling app has a permission
to the data it is about to proxy which leaves a trace in app ops
that the requesting app perofmed a data access. However, then the
app doing the work needs to get the protected data itself from the
OS which access gets attributed only to itself. As a result there
are two data accesses in app ops where only the first one is a
proxy one that app A got access to Foo through app B - that is the
one we want to show in the permission tracking UIs - and one
for the data access - that is the one we would want to blame on
the calling app, and in fact, these two accesses should be one -
that app A accessed Foo though B. This limitation requires fragile
one off workarounds where both accesses use the same attribution
tag and sys UI has hardcoded rules to dedupe. Since this is not
documented we cannot expect that the ecosystem would reliably
do this workaround in apps that that the workaround in the OS
would be respected by every OEM.
This change adds a mechaism to resolve this issue. It allows for
an app to create an attribution context for another app and then
any private data access thorugh this context would result in a
single app op blame that A accessed Foo though B, i.e. we no longer
have double accounting. Also this can be nested through apps, e.g.
app A asks app B which asks app C for contacts. In this case app
B creates an attribution context for app A and calls into app C
which creates an attribution context for app B. When app C gets
contacts the entire attribution chain would get a porper, single
blame: that C accessed the data, that B got the data from C, and
that A got the data form B. Furthermore, this mechanism ensures
that apps cannot forget to check permissions for the caller
before proxying private data. In our example B and C don't need
to check the permisisons for A and B, respectively, since the
permisisons for the entire attribution chain are checked before
data delivery. Attribution chains are not forgeable preventing
a bad actor to create an arbitrary one - each attribution is
created by the app it refers to and points to a chain of
attributions created by their corresponding apps.
This change also fixes a bug where all content provider accesses
were double counted in app ops due to double noting. While at
this it also fixes that apps can now access their own last ops.
There was a bug where one could not pass null getting the attributed
ops from a historical package ops while this is a valid use case
since if there is no attribution everything is mapped to the null
tag. There were some app op APIs not being piped thorough the app
ops delegate and by extension through the app ops policy. Also
now that we have nice way to express the permission chain in a
call we no longer need the special casing in activity manager to
handle content provider accesses through the OS. Fixed a bug
where we don't properly handle the android.os.shell calls with
an invlaid tag which was failing while the shell can do any tag.
Finally, to ensure the mechanims is validated and works end-to-end
we are adding support for a voice recognizer to blame the client
app for the mic access. The recognition service can create a blaming
context when opening the mic and if the mic is open, which would
do all permission checks, we would not do so again. Since changes
to PermissionChercker for handling attribution sources were made
the CL also hooks up renounced permissoins in the request permission
flow and in the permission checks.
bug:158792096
bug:180647319
Test:atest CtsPermissionsTestCases
atest CtsPermissions2TestCases
atest CtsPermissions3TestCases
atest CtsPermissions4TestCases
atest CtsPermissions5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Change-Id: Ib04585515d3dc3956966005ae9d94955b2f3ee08
-. Remove VoidResultCallback of setImeWindowStatus
and let it be asynchronous.
-. Rename function naming to setImeWindowStatusAsync.
Bug: 183587528
Test: atest CtsInputMethodTestCases
Change-Id: Ia9f19ca5ae418089ce43816dcd50487e1b1172f1
