It's unclear why it was put in the first pinner implementation, and we
may now get symbolic links returned by ART's metadata files.
Test: boot and see that there's no pinner warning
Bug: 185833667
Change-Id: I6cb1a5a9f684c7f0e61bb7fca394030d5dd30c58
When zero total size, should update progress to zero.
Bug: 185869705
Test: atest UsageProgressBarPreferenceTest
Change-Id: I02dae2fbea23b56dad07941c614d9ef3500eeae4
There was confusion as to whether updateBluetoothStateLocked
took an ActivityInfo representing a cumulative total or a delta.
It is confirmed that it is now a cumulative total. (It had been
a delta in the past, but no longer.)
Bug: 174818545
Test: N/A (just comments)
Change-Id: I62130f22250eb496164f94c0668d1ff65fed7710
Connectivity CTS tests were moved from cts/tests/net to
packages/modules/Connectivity.
Bug: 185751610
Change-Id: Id4efd99c419706a52ad5d708888097bd6312d4e6
Test: treehugger is needed to test
The test simply creates an exception and verifies that it has the
required fields.
The constructor tests are only run on S+ as they are not part of the
API before that.
Change-Id: Ic30a34d3203c1b40923ba783a34f0cfed53a07ae
Test: atest FrameworksNetTests
S tethering module fail to sideload in R platform because package
manager fail to parse S version sdk in R platform.
Bug: 182409819
Test: m
Change-Id: I35c63e4bfe7657afe1e7364926ab139b042b403e
Merged-In: I35c63e4bfe7657afe1e7364926ab139b042b403e
S tethering module fail to sideload in R platform because package
manager fail to parse S version sdk in R platform.
Bug: 182409819
Test: m
Change-Id: I35c63e4bfe7657afe1e7364926ab139b042b403e
Previously WindowContext is removed if the associated WindowContainer
is removed. However, it causes an issue that WindowContext is removed
unexpectedly after the last window is removed by WM#removeView().
When the last view is removed, WMS will remove the WindowToken
in postWindowRemoveCleanupLocked(), and if the WindowToken is created
by WindowContext, the associated WindowContext is also removed
unexpectedly.
This CL makes WindowContext switch back to listen to the previous
DisplayArea if the last window is removed.
Test: atest WindowContextListenerControllerTests
Bug: 185460076
Change-Id: I9c1d0c15c77bbfb3662355f8c72f0d8c70ed6748
IACC#activityTopResumedStateLost was reported to ATMS later than
IACC#activityPaused sometimes because one is one-way binder call
while the other one is two-way binder.
Also make IACC#activityTopResumedStateLost a two-way binder
Bug: 185810414
Test: atest ActivityLifecycleTests
Change-Id: Ib87de693f5ebcfd836208924aa8fc2a035ca7c82
isForeground is not a good approach to indentify current channel info
And add a permission for tuned info.
Bug: 180482268
Test: atest CtsPermission2TestCases
Test: atest TvInputManagerTest#testGetCurrentTunedInfos
Change-Id: Ib1c1f2da719336ae856684e843b06f8b9b442723
Address API review feedback, add getters to UnderlyingNetworkInfo
instead of exposing fields.
Instead of wasting memory by converting this into an array, have
migrateTun take a List<String>. In turn, tunAdjustmentInit should
also take a List<String>.
Bug: 183972554
Test: atest android.net.UnderlyingNetworkInfoTest
Change-Id: Id59744097208d91298a25ef110ade91a9cf291a1
For multi-display device, like pixel_jumbojack, when this device is
folded, the secondary display is removed. The A11y framework stops
tracking windows on the removed display by un-registering its
callback.
When the A11y framework un-registers a callback, it checks if the
display is embedded. If it is, the observer is not removed since
the same observer will be observing the parent display.
When the display disappears entirely, however, its context
disappears and there's no way to know if it was embedded or not.
The observer was therefore not removed. When the device is unfolded
and the display reappears, the attempt to register an observer
causes an exception because the previous one is still there.
Due to there's no multi-display device for android S now, so we
adopt simple solution as below to fix it:
1. Throws the exception for debug builds only.
2. Adds this exception into the error log.
3. Recovers by unregistering the current observer and proceeding to
register the new one
The fully solution will phase in the master.
Bug: 182963008
Test: a11y CTS & unit tests
Change-Id: Iff9776ac6e054c0198c0d8739d9446a785716612
... te improve readability.
Also change remaining ctr's visibility to protected for
ActivityRecord and WallpaperWindowToken to inherit.
Test: touched tests
Bug: 185460076
Change-Id: I3437771d417fd19ea58414e2189e2126bbcc1901
Bug: 183496853
Test: visual verified
1) Settings -> Notifications -> Notification history
2) Observe and see if the new animation is applied
Change-Id: Ic4b584b10a27c8e17075b044e659b5dc3e3fec87
Correctly count nri uid request counts in the per-app functionality in
connectivity currently used by set profile and set oem network
preference APIs. Previously, upon creation, nris would be created prior
to removing them. This would cause the uid request counts to
artificially increase and incorrectly throw an error if the request
count limit was hit even though in actuality an apps request count was
valid.
E.g., if there was an existing request for per-app functionality and
its owning app made a change to the per-app requests, it would double
count the existing requests. If the current count was say, one under the
limit, an error would be thrown even though it was being replaced which
should have resulted in no net change to the request count limit if
working correctly.
This patch will allow for the requests to be removed prior to creation
so that request counts are tabulated correctly.
Bug: 185849563
Bug: 183785319
Test: atest FrameworksNetTests
Change-Id: I13da0c81256cc02bea6aff2fe1ef99d6f6b0e764
Bug: 185534915
Test: mp :BatteryStatsViewer && adb shell am start -n com.android.frameworks.core.batterystatsviewer/.BatteryStatsViewerActivity
and check that custom component is displayed as "GPU", not "CUSTOM_10000"
Test: atest FrameworksServicesTests:com.android.server.am.MeasuredEnergySnapshotTest
Change-Id: Ibb68bb2ee62678db5f3b30c4f2ef607006ccc81b
- use getPackageManagerForUser when looking up app info
- add test for it
Bug: 184041127
Test: atest BubblesTest
Test: - have a managed work profile
- install the bubbles app *only* for the work profile
- make some bubbles
=> Notice bubbles appear
- dismiss all the bubbles
- restart the device, add a bubble
- open the bubble, navigate to the bubble overflow
=> notice the previously dismissed workprofile bubbles
are in the overflow
Change-Id: I479bb717b3c365346682331b0def7170ed1a791b
* Persist bubbles per-user - rather than one list the
XML now has a list per-user. The entries in these lists
still include userId for workprofile since bubbles are
mixed in the stack / overflow for workprofile.
* When loading bubbles, only the ones for the current user
are loaded / hit bubbleController code
* When user changes, overflow data should be re-loaded
* Allow the bubble window to be visible for all users
Test: atest BubbleXmlHelperTest BubbleVolatileRepositoryTest
BubblePersistentRepositoryTest BubblesTest
Bug: 173408780
Change-Id: I88cb7cc7ee676d8e0756328a95a54fdaf018a013
* Move bubbles setting from the global table to the secure
table, this should be a per-user setting
* Update step in SettingsProvider that adds the secure
setting based on the value of the previous global, or if
the user is managed, it checks if the owner of the managed
user has a secure setting & uses the value from that to
insert the new setting.
* Adds the secure setting to the "cloned to profile"
group since it should follow the setting of the profile
owner.
* PreferencesHelper tracks this value per-user.
Bug: 173408780
Test: atest PreferencesHelperTest NotificationManagerServiceTest BubbleExtractorTest
Change-Id: I261364890fcc54fb2791e628b41c07aeddde3974
The API windowSplashScreenBackground should work even when starting
window controller request to create an empty icon splash screen.
Bug: 182759603
Test: atest SplashscreenTests
Change-Id: I0c8178f27663f92acfdd0da8d216ff7ae94db981