These fields are accessed to clean up leaks on older versions,
but they shouldn't be accessed anymore.
Fixes: 123768581
Fixes: 123768639
Fixes: 123769388
Test: no code changes
Change-Id: I7265109290ba11477837bd09136b1d6ef5c73702
The API was dark grey listed in P, and it was greylisted in commit
76907ee.
Move it back as we should not be making API less restrictive in new
letter releases.
Test: m
Bug: 123987101
Change-Id: I0b43e31cb1d3d1c170d6718d3f71e21841ec30dc
This method was on the dark grey list in P. It was removed sometime in
the meantime, and re-added in commit 01053cd, but put onto the grey list
rather then the max-sdk-o greylist (equivalent to dark grey in P).
Move it back as we should not be making API less restrictive in new
letter releases.
Test: m
Bug: 123987101
Change-Id: I5ec57e6523f2d0881e0e4e5597009fc2717bfb85
The API was dark grey listed in P, and it was inadvertantly moved on the
max-sdk-p greylist in commit 01053cd.
We should not make greylist APIs less restrictive between letter
releases as this makes the situation confusing for developers.
Test: m
Bug: 123987101
Change-Id: I2b8675c7e15479a6e8121976329fec88558f8cad
The CL transitions View#scrollX and View#scrollY to the dark gray list,
not usable by reflection starting with Q. Instead of accessing them,
developers should use getScrollX(), getScrollY() added in API 1 and
setScrollX(int), setScrollY() added in API 14.
Bug: 123769508
Test: none
Change-Id: I166b9fe897bd35fd97b2e1fc2a8df73691255688
This lets us run experiments that need to know the reason for the wake
up in addition to the time and latency.
Bug: 122949636
Test: manually turning the device on and off, looking at the logs
Change-Id: I38429c3387a289010e1a2696ad351ffbe568413b
This is the first step to a few things including allowing for virtual nodes to have view backed descendants and siblings.
The main change in findViewByAccessibilityId SPI (its changed name and location, but it still is effectively the same thing) is that if something has a nodeProvider it will now still return view children.
I sifted through each use of the SPI and determined if they were an issue, and cleaned up any code in the process (Autofill cleanup is coming in a different CL).
Test: added a few simple unit tests, used talkback on system in a few places including virtual views, atest accessibility*, cts accessibility* (There were some failures here but they don't seem to be caused by this change, those are captured in these bugs b/120628276 b/120890822), CtsAutoFillServiceTestCases
Bug: 37714287
Change-Id: Id5807114fbb4c932eaea275dc2d94d0dbe25a8ae
Restricted access to setAlphaNoInvalidation method on View class.
Consumers should be able to handle the same functionality by leveraging
the onSetAlpha method within a View subclass. Removed usages of
setAlphaNoInvalidation within ViewPropertyAnimator.
Change-Id: Ieab3d54313972051484ac591b6f4329d3ae7b0cc
Fixes: 123768435
Test: Re-ran CtsAnimationTestCases
This was done in preparation for making changes related to
@UnsupportedAppUsage while trying to understand the semantics
of certain fields and the methods that use or modify them.
Bug: 123768420
Bug: 123768921
Test: No code changes.
Change-Id: I449be366906100c385ee610ce33953ddf0fb4ef0
1. Pull out the common intent genereation logic to TemplateIntentFactory,
so that it could be used by actions.
2. Fix a bug that we are freeing the annotator immediately when
we are switching annotator model file. It is incorrect as
it could be used by another thread / model.
Test: atest frameworks/base/core/tests/coretests/src/android/view/textclassifier/
BUG: 123745079
Change-Id: I6c5364595470b900be2dd976dda6e9fc90464de9
It turns out that AppRestrictionsHelper#addSystemImes() has always
queried for the owner user's system IMEs despite the fact that it's
trying to query system IMEs for a restricted profile user. This
behavior has not changed since its beginning [1].
Most likely people would not have noticed this though, because:
* Settings app does not show a menu item to create a restricted user
on phone devices.
* Even if it's available, most people do not use restricted users.
* Even if someone created a restrected user, most likely the owner
user and the restrected user share the same set of system IMEs,
which are defined as "pre-installed" IMEs.
Anyway, AppRestrictionsHelper#addSystemImes() will start using a newly
introduced @hide API IMM#getEnabledInputMethodListAsUser() so that it
can query for the right user's system IMEs, instead of querying owner
user's ones.
[1]: Ifced841ad3bfbde33d2403356216dd1749b7fa9a
a7a93784d1f9798d37cb618def1a558f8d626f0f
Bug: 122164939
Test: atest SettingsLibTests:AppRestrictionsHelperTest
Test: manually done as follows.
1. Build aosp_taimen-userdebug and flash it.
2. adb shell pm create-user --restricted test_profile
3. adb shell am start -a android.settings.USER_SETTINGS
4. Click the gear icon next to the "test_profile" user.
5. By adding a log, make sure that IMMS#getInputMethodList()
gets called with userId = 10.
Change-Id: I5b50b5fe143c74c87b331bda3e5bcc4d6248436e
Restricted reflection access to:
- dispatchAttachedToWindow
- dispatchDetachedFromWindow
Those should not be used directly as it violates internal code
guarantees. Instead Views need to be actually attached to the window.
Bug: 123769352, 123769370
Test: n/a
Change-Id: I0006bc99a2d10747e931e944caee21932c4642dd
Developers should use setTransitionVisibility instead of using
reflection to change the visibility in mViewFlags directly.
Bug: b/123768691
Test: CTS test in topic
Change-Id: I04d76100c53238b92cdc1575bc20af2a6b4410fe
This CL fixes a regression introduced by my previous CL [1], which
enabled InputMethodManager#getEnabledInputMethodList() to return the
result based on the caller's user ID, not based on the current IME
user, even when it gets called from background users.
Since Keyguard always runs as user 0 currently, it is now Keyguard's
responsibility for querying enabled IMEs with an explicit user ID. To
do so this CL adds a @hide API IMM#getEnabledInputMethodListAsUser()
and lets KeyguardPasswordView use it.
[1]: I192a0f5a1375170d17a4c08af94f23966dbaea8b
7f8ee4b9dd
Bug: 122164939
Fix: 123904896
Test: Manually verified as follows.
1. Build aosp_taimen-userdebug and flash it.
2. make -j SoftKeyboard
3. adb install -r $OUT/system/app/SoftKeyboard/SoftKeyboard.apk
4. adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
5. adb shell pm create-user test_user
6. adb shell am switch-user 10
7. adb shell locksettings set-password aaaa
8. adb shell wm dismiss-keyguard
9. Make sure that the IME switcher icon is not shown at the right
end of the password field.
Change-Id: I6e7d7353c2b5b1da5d460ae005fb2585f85fb1c4
This is a follow up CL to my previous CL [1], which enabled following
IME query APIs to return the result based on the caller's user ID, not
based on the current IME user, even when they get called from
background users.
* InputMethodManager#getInputMethodList()
* InputMethodManager#getEnabledInputMethodList()
* InputMethodManager#getEnabledInputMethodSubtypeList()
This CL just clarifies it in the API documents.
This is purely a document fix. There should be no behavior change.
[1]: I192a0f5a1375170d17a4c08af94f23966dbaea8b
7f8ee4b9dd
Bug: 13002424
Bug: 122164939
Test: make -j checkbuild
Change-Id: I55f51e211a8a47c01469e2d93b04c5c864f0b9ea
Users should rely on the getter / setter. The setter additionally
guarantees internal state correctness.
Bug: 123768937
Test: n/a
Change-Id: Ia2dcbe9db3fdeab8aeac9b80dcfaaa0932724dc2
Most calls are bufffered anyways, so by not using a handler we save time spent
on getting a pooled lambda and posting to the the handler.
The only "expensive" operation is flushing, but it makes a oneway binder call
so it might be fine (and if necessary, we can optimize it later).
Bug: 123307965
Test: atest CtsContentCaptureServiceTestCases
Change-Id: I7182c8e193f58fa000396fdb3003e771214bf79b
The overall workflow of Content Capture is:
- send initial structure
- send deltas afterwards
Initially, the initial structure was being reported one view at time, which was causing janking.
This CL changes it so while that while the initial structure is being laid out, the content captures
are held. Then after it's finished, it traverses the structure and sends the initial events.
This change also allowed use to optimize the performance by caching the following state:
- View.isImportantForContentCapture()
- View.getContentCaptureSession()
- Context.getContentCaptureManager()
Besides the performance improvements, this approach also has the following advantanges:
- It sends the VIEW_APPEARED events for the parent views before the events for the children.
- It send events to notify when the view structure layout is ready.
Bug: 123307965
Test: atest CtsContentCaptureServiceTestCases
Test: m update-api
Change-Id: I6db7cc11c6edf65cbffe42187fda82c84c3665ff
This seems to be used to force action bar to show an overflow
menu. Perhaps this functionality needs to exist in Toolbar,
but after discussion with the team, we have decided it does not
need to be supported in this fashion any longer.
Bug: 123768915
Test: No API or behavior changes
Change-Id: I8e311133faec599f4dee635e261507521318260e
A few getters for view properties have been added where they were
missing. CTS tests for the new APIs are pending in b/123894719.
Test: m framework
Bug: 120492712
Change-Id: I743ce693d384eaf749ced3db7f81bda7d19ed275
This is a value provided by ViewConfiguration that is standardized
across the device. There are two problems in changing this:
1. inconsistent behavior with the rest of the uses
2. modifying this would open the door to modifying all slops,
which is infeasible and has no good API story
Bug: 123769434
Test: No API or behavior changes
Change-Id: I30bc9d065be8633752a67bd0faa9eafe1678e843
