summaryrefslogtreecommitdiff
path: root/core/java/android/view/WindowManagerGlobal.java
Commit message (Collapse)AuthorAgeFilesLines
* Remove view based on known index of the view on exceptionBeverly2022-07-151-1/+1
| | | | | | | | | | | | There's no need to findViewLocked - if the view didn't already exist, then the view is added to the end of the mViews list. findViewLocked will need to iterate over all the views which is unnecessary. Test: manual Fixes: 238954722 Change-Id: I3a22f59df84f512d4e914f0e3566927450284298
* Make sure to cleanup views that couldn't be addedBeverly2022-07-011-2/+3
| | | | | | | | | | | | | | | ie: due to BadTokenException or InvalidDisplayException Previously, only views that were already in the viewhierarchy before attempted to be re-added would be removed. This makes sure if the view was newly added, it'll also be removed. This prevents a memory leak of views. Test: manually show and cancel multiple toasts, check the hierachy viewer that no Toast views remain Fixes: 234694098 Change-Id: I06bbae70c277d0615753edc9ec0a8e7439ad7020
* Prevent windows from drawing if they're in an active sync setchaviw2022-06-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | If a window is in a sync, but it already drew it's sync buffer, it normally would be allowed to continue processing draws and just block when it runs out of buffers. It would unblock once the sync is complete at the sync buffer was sent to SF. However, this has a few issues 1. In some cases, WMS wants to retry the draw again due to configuration changes. This could cause deadlocks because the client may already be blocked since there are no more buffers. Instead, the client will block and WMS would be responsible for dropping the last buffer and notifying the client that it can draw for a sync again 2. If there are multiple UI threads, each can block each other due to the shared Render Thread. If one of the windows in the sync continues to draw and then blocks RT due to no more buffers, all other UI threads are unable to draw. If the behavior in 1 is desired, we'd need to make sure no one in the same sync continues to draw until everyone is complete. This is to ensure dropping will actually allow another render to occur. If other windows are blocking the RT, then even with dropping, the requested sync window cannot get another buffer and will cause a deadlock. Test: Current sync requests work Bug: 233625646 Change-Id: I3a0a4f36bf61a6677507672578e447060b806651
* Introduce WindowlessWindowLayoutTiger Huang2022-04-221-1/+1
| | | | | | | | | | | | | The window frame computed by WindowlessWindowManager doesn't take the window bounds, insets state, gravity, ... into account, but only width and height in LayoutParams. This CL introduces WindowlessWindowLayout which aligns the logic in WindowlessWindowManager#relayout. When we enable LOCAL_LAYOUT, the frame of windowless window will be compatible. Bug: 161810301 Bug: 175858823 Test: atest SurfaceControlViewHostTests#testEmbeddedViewResizes Change-Id: I460445e9d6b61117edbdaddeac6a00a838b3caa8
* Allowing SurfaceViewHost to show up in layout inspectorSunny Goyal2022-04-071-1/+9
| | | | | | Bug: 191298629 Test: Verified on device Change-Id: I83c74423b6f33f45cdd93926badb2cad32c7a86d
* Push drag-resize mode to the clientTiger Huang2022-03-201-16/+2
| | | | | | | | | | | | | | | The goal of this CL is to remove RELAYOUT_RES_DRAG_RESIZING_DOCKED and RELAYOUT_RES_DRAG_RESIZING_FREEFORM, which is a step to make relayout an oneway binder call. When the resize mode is changed at the server side, the server will send the new mode to the client via IWindow#resized, so the client doesn't need to obtain the resize mode from the flags returned from relayout. Bug: 161810301 Test: Perform drag-resize and drag-move on a freeform task and see if there is any unexpected behavior. Change-Id: I450abc113932b6c1dc0ce0e2b76bebdf85a60777
* Async BLAST Sync [2/N]: Introduce seqIdRobert Carr2022-03-171-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | We introduce a seqId and use it to replace the RELAYOUT_RES_BLAST_SYNC flag. The server code block that produces RELAYOUT_RES_BLAST_SYNC is guarded by mNextRelayoutUseSync, and sets it to false when executed. This block is the only place that sets it to false. We replace every place where it is set to true, with incrementing a seqId stored on the integer. We change this block to not check mNextRelayoutUseSync but instead check if the seqId has changed since we reached the block. This is evidentally equivalent conditions and in these cases we send the client the seqId. In the else block where we wouldn't have sent RELAYOUT_RES_BLAST_SYNC we send -1. On the client side, we replace the USE_BLAST_SYNC conditional with a check if the SeqId we received has increased. It's clear that this will never execute in cases where the seqId is -1. Likewise its clear that if the seqId has increased, it will execute. Since the seqId increases in all cases where the server would have returned RELAYOUT_RES_BLAST_SYNC this change is a noop by itself. Bug: 161810301 Bug: 175861051 Bug: 175861127 Bug: 200285149 Change-Id: Ib2e45cae7709519251e4bfcc2b8adc689c590a00
* Remove RELAYOUT_RES_IN_TOUCH_MODETiger Huang2022-03-151-13/+7
| | | | | | | | | | | | | | When WindowManagerService.mInTouchMode is changed, we will set the new mode to InputManagerService, and clients will be notified via ViewRootImpl.WindowInputEventReceiver#onTouchModeChanged. We don't need the flag to bring the information to the client. This is also a step to make relayout an oneway binder call. Bug: 161810301 Test: Invoke View#requestFocusFromTouch on one window and see if another window can receive OnTouchModeChangeListener#onTouchModeChanged. Change-Id: Ic149c95bee89b2be83a85eb4858131224b63a7c8
* [ShellTransition]: add WMS#setRecentsAppBehindSystemBars for recentsMing-Shin Lu2022-02-261-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For legacy recents animation, launcher side use RecentsAnimationController#setAnimationTargetsBehindSystemBars to callback if the animating recents task target is valid to affect system bar apparence according the gesture threadshold. if the animating recents task is behind system bar, means the gesture threshod not yet passed and the task still can affect system bar apparence, and vice-versa. with shell-transition, since launcher triggers recents animation by normal startActivity without initiating RecentsAnimationController with startRecentsActivity, the launcher will be top-resumed (but the surface hierarchy the recents task is still be top-most) when starting gesture on navbar, in this case, launcher can affect the system appearence even though launcher is behind systembar. beside, previously we also rely on setAnimationTargetsBehindSystemBars to hide soft-keyboard in multi-windowing mode when quick-swich tasks, without this, soft-keyboard will keep visible when swiping up to recents. As the result, we needs to backport the most logic of setAnimationTargetsBehindSystemBars for fixing the above cases, the only difference is we renaming the method with setRecentsAppBehindSystemBars(behindSystemBars) to only set recents app can affect systembar apparence, and placing hide IME/IME icon logic into handleLegacyRecentsStartBehavior when starting recents animation. Fix: 215504556 Test: manual as below CUJs with enabling shell-transition: CUJ1: 1) Launching a app with showing IME 2) Quick-switching to the next task or swiping task to home 3) Expect no navbar icon flickering CUJ2: 1) With entering split-screen and showing IME on the split task 2) Swipe up to recents 3) Expect IME shound be hidden CUJ3: 1) Launching a app 2) Hammer tapping on the navigation bar 3) Expect the staus bar icon won't blinking Change-Id: I552eea738aed5566eb897bb9c68507e83ac43e1d
* SurfaceControlViewHost: Basic child window supportRobert Carr2022-02-091-1/+35
| | | | | | | | | | | | WindowlessWindowManager already has some support for multiple windows so the main thing we need to do is just ensure that the Windowless session is injected in to the ViewRoot of things attached to our token. We can do this via some somewhat unsightly glue code in WindowManagerGlobal. Bug: 218615203 Test: SurfaceControlViewHostTests Change-Id: Icce97c02b6155a7ef368821670db26728b95b6b9
* Expose mirror of wallpaper surface in WindowManagerGlobal.Brian Isganitis2021-10-191-0/+11
| | | | | | Test: Manual Bug: 188222480 Change-Id: I92302053a797de76aec3c2a25e5d895cfc85e6d5
* Remove legacy disable triple buffering configVishnu Nair2021-03-161-1/+0
| | | | | | | | | | | | | | The config changes the dequeue limit of BQ (setMaxDequeuedBufferCount) from 2 to 1, decreasing the default size of the queue from (3 to 2). Some of the motivations behind this change include: - not applicable in most scenarios since producers in the system override this - breaks async mode, not well tested in other scenarios - simplifying some of the implementation and removes a configuration/flag. Clients can still manually call setMaxDequeuedBufferCount if they wish. Test: presubmit Fixes: 182314340 Change-Id: I724218d14ad106a4b7af69f7eacf97fae3c93923
* Remove addWindowTokenWithOptionsCharles Chen2021-02-061-1/+0
| | | | | | | | | | | Since WindowContext won't add WindowToken from the client side, addWindowTokenWithOption is no more needed. Also remove the logic to invoke removeWindowToken from the client side. Bug: 159767464 Bug: 153369119 Test: atest WindowManagerServiceTests WindowManagerPermissionTests Change-Id: Ib0c948dca223cf8d056865ce3a0d4adaef07d247
* Remove preserve surfaceschaviw2021-02-051-8/+0
| | | | | | | | | | | | | | | When using blast, there's no need to call preserve surfaces since the client can synchronize layer changes with the incoming buffer in the new size. If the client uses the WindowOrganizer.applySync call they can ensure they only update the layer geometry in the same transaction that the new buffer is submitted in. When removing preserveSurfaces, we can also remove reparentChildren since that was the only caller of reparentChildren Test: Split with SurfaceView Bug: 177557720 Change-Id: I4574ac0d3b8a63b13ac44846e729b73ca0f88f23
* Add maxTargetSdk restriction to unused APIs.Mathew Inwood2020-10-291-2/+2
| | | | | | | | | | | | | | | | | | | These are APIs that have @UnsupportedAppUsage but for which we don't have any evidence of them currently being used, so should be safe to remove from the unsupported list. This is a resubmit of ag/12929664 with some APIs excluded that caused test failures; see bugs 171886397, 171888296, 171864568. APIs excluded: Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord; Landroid/os/Process;->myPpid()I Landroid/os/SharedMemory;->getFd()I Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I Bug: 170729553 Test: Treehugger Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
* Revert "Add maxTargetSdk restriction to unused APIs."Hongwei Wang2020-10-281-2/+2
| | | | | | | | | This reverts commit 72f07d6a8a32db4a0dedd7682a0b3385be2b9cd6. Reason for revert: Droidcop-triggered revert due to breakage https://android-build.googleplex.com/builds/quarterdeck?testMethod=testAppZygotePreload&testClass=android.app.cts.ServiceTest&atpConfigName=suite%2Ftest-mapping-presubmit-retry_cloud-tf&testModule=CtsAppTestCases&fkbb=6936597&lkbb=6936969&lkgb=6936551&testResults=true&branch=git_master&target=cf_x86_phone-userdebug>, bug b/171886397 Bug: 171886397 Change-Id: Ibe0f0430a3451477c1ee8ef56a596e91ea1e7672
* Add maxTargetSdk restriction to unused APIs.Mathew Inwood2020-10-271-2/+2
| | | | | | | | | | These are APIs that have @UnsupportedAppUsage but for which we don't have any evidence of them currently being used, so should be safe to remove from the unsupported list. Bug: 170729553 Test: Treehugger Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
* Remove some dead codeJohn Reck2020-10-161-16/+15
| | | | | | | Simplify state by deleting unused & always true stuff Test: builds Change-Id: Idf679aff5e809e567dac21a127cb9d6ace894f0e
* Merge "BLAST: Two start-up optimizations" into rvc-devRob Carr2020-04-271-1/+3
|\
| * BLAST: Two start-up optimizationsRobert Carr2020-04-241-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 1. Avoid a seperate IPC querying in to system-server to initialize the mUseBLAST flag. 2. Avoid calling property_get_bool with each BufferQueue creation. Instead we piggy-back both values inside addWindow return values. Bug: 152501005 Test: Existing tests pass Change-Id: If130560a8230f8d399cf7631264d551522939faa
* | Limit number of window context without any windowCharles Chen2020-04-221-0/+1
|/ | | | | | | | | | | | | | | | | | | | | | | This change is to prevent misuse of window context from app and leads to performance drop on system by limit the numer of window context an app can use. Code snippet below is a sample to cause this issue: ``` Rect getBounds() { Context windowContext = context.createWindowContext(...); return windowContext.getSystemService(WindowManager.class) .getCuttentWindowMetrics().getBounds() } ``` This method could be invoked dozens of times and produce dozens of window tokens. It would slow down the speed of window traversalling. These token won't be removed until system server has been GC'd. Test: atest WindowContextTests WindowContextPolicyTests fixes: 152934797 Bug: 153369119 Change-Id: I927e85a45c05c4d90b51a624ea408ff3a3ffce93
* Merge "Support addWindow as other user" into rvc-devWei Sheng Shih2020-04-101-2/+3
|\
| * Support addWindow as other userwilsonshih2020-04-081-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Support addWindow with the other userId which can be different from Uid. This can be used when client want to addView for secondary user. Example: 1. Create context with createContextAsUser or similar method. 2. Get WindowManager with this context. 3. WindowManager#addView Bug: 151414297 Test: atest WmTests WindowAddRemovePerfTest AddWindowAsUserTest Change-Id: I13e58d76b1f056f3829bc984c2b61496c8f8d535
* | ViewRootImpl: Pass buffer to finishDrawing when requestedRobert Carr2020-04-081-0/+8
|/ | | | | | | | | | | | | | | As the final enabler for the BLASTSyncEngine, we add a new relayout result BLAST_SYNC. If the WindowState is participating in a BLAST sync during relayout we return it to the client. If we return it to the client the client will direct it's next draw in to a BLAST transaction and report that transaction via finishDrawing. You can now observe the BLASTSyncEngine working end to end in TaskOrganizerMultiWindowTests. We do a few small clean-ups in TaskOrganizerMultiWindowTest while we are there. Bug: 153561718 Test: TaskOrganizerMultiWindowTests Change-Id: I719b731350b942aafa444a33972aaef8973422ea
* Use separate thread if app doesn't listen to animationsJorim Jaggi2020-03-111-0/+8
| | | | | | | | | | | There is no need to introduce jank risk and run the inset animations on the main thread if the app doesn't listen to animation events. In that case, move the animations onto a separate thread. Bug: 118118435 Test: Inspect systrace Change-Id: Ib6e4b4ce8e9dd8e27761ced6eb8d7700b6236a32
* Query for BLAST flag outside of constructorValerie Hau2020-02-101-8/+4
| | | | | | | | | | | | WindowManagerGlobal should query for flag only when the service has successfully been retrieved. Moving query into block where sWindowManagerService is initalized Bug: 149243163 Test: build, boot, adb shell device_config put window_manager_native_boot wm_use_blast_adapter true/false Change-Id: I864d60158236059fda9844844b07299bb97ee6d1
* Move BLAST flag to WindowManagerServiceValerie Hau2020-02-071-7/+13
| | | | | | | | | | | | | Querying flag property in preloaded class static initialization removes it from preloading and increases boot time. Move query to WindowManagerService instead when constructed Bug: 148614188 Test: build, boot, adb shell device_config put window_manager_native_boot wm_use_blast_adapter true/false check that BLAST adapter is turned on/off as expected Change-Id: I02e2327b5c2cb11a231d02fc2c5c8c1ac200aaf0
* Revert to false for BLAST flag until boot time issue resolvedValerie Hau2020-01-271-5/+1
| | | | | | Bug: 148229181 Test: build, boot Change-Id: Ia9ffd14c396ca3e0d84b9aaa21ba700ee88dd983
* Merge "Adding WINDOW_MANAGER_NATIVE_BOOT and ↵Valerie Hau2020-01-211-1/+7
|\ | | | | | | window_manager_use_blast_adapter flags"
| * Adding WINDOW_MANAGER_NATIVE_BOOT and window_manager_use_blast_adapter flagsValerie Hau2020-01-211-1/+7
| | | | | | | | | | | | | | | | | | | | | | For ViewRootImpl on BLAST experiment, setting up namespace and flag to turn on Blast adapter through P/H experiment Bug: 147096935 Test: build, boot, adb shell device_config put window_manager_native_boot wm_use_blast_adapter true/false check that BLAST adapter is turned on/off as expected Change-Id: Ie1b158721ac9b751fcf3954310259f14486d3bb8
* | Introduce ImeFocusControllerlumark2020-01-161-5/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduced ImeFocusController to manage IME focus target and retrieve IME target event from ViewRootImpl. With this CL, removed InputMethodManager focus check related methods and replaced with below methods in ImeFocusController: - onPreWindowFocus - onPostWindowFocus - onViewFocusChanged - onViewDetachedFromWindow - onWindowDismissed - onProcessImeInputStage Since all methods are guaranteed to interact within View or ViewRootImpl with UiThread, so it also benefits that we can without any lock protection, and ViewRootImpl will no longer depend on InputMethodManager methods call in the end. Also, Add mHasImeFocus in View.AttachInfo, for propogating if this view's window is IME focused, if so, View#notifyFocusChangeToInputMethodManager -> ImeFocusController#onViewFocusChanged will be called to notify the focus change to corresponding IME focus controller. Bug: 141738570 Test: atest SearchViewTest, FocusHandlingTest Test: atest ActivityViewTest, MultiDisplayClientTests, MultiDisplaySystemDecorationTests Change-Id: Ib455704fe1e9d243f93190a84f230210dbceac2a
* Switch BLAST flag to WindowManagerGlobalValerie Hau2020-01-071-0/+6
| | | | | | | | | Setup for P/H experiment by switching to WindowManagerGlobal. Follow up patch will set the flag based on DeviceConfig Bug: 147096935 Test: build, boot, manual Change-Id: If062fc16a90e0f3069064b969e1a63a6142421df
* Use new UnsupportedAppUsage annotation.Artur Satayev2019-12-181-1/+1
| | | | | | | | Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library. Bug: 145132366 Test: m && diff unsupportedappusage_index.csv Change-Id: I5be7335b23a92b8ac80d2fd890198273b66ad644
* Improve dumping of display list memory usageJohn Reck2019-10-091-12/+10
| | | | | | | | The first step of improving is measuring. So measure better. Bug: 138856108 Test: dump Change-Id: I076b904a1f0dfb209622c76bcb8778a10cd2b7db
* Invoke setWindowStopped on the thread that created the viewRiddle Hsu2019-05-151-1/+19
| | | | | | | | | | | | | | | | The windows belong to a activity will be set to stopped state when the activity is stopped. But the associated thread of view root could be different from activity, that results the inconsistent calling thread of surface callback, and maybe some potential races. Since the surface could be destroyed during traversal, also add a check for callback notifySurfaceDestroyed to prevent duplicated calls if the surface is released. Bug: 130553315 Test: atest ViewRootSurfaceCallbackTest Change-Id: Iea2cf8ff51118c0fa8c00a35c1d3e53c959ea754
* Provide a hook for forcing all system bars to be displayed at all timesBrad Stenning2019-03-201-6/+7
| | | | | | | Bug: 121257946 Test: manual Change-Id: Ibbf41a03b0229b62366a42543e542af954a0ea8b
* Public API for statically accessing global list of window viewsAlan Viverette2019-02-151-0/+11
| | | | | | | | | | Android Studio's UI inspection tool needs access to the currently displayed window(s) via publicly-accessible APIs given only a classloader -- it does not have any activity or app Context. Bug: 124516440 Test: atest WindowInspectorTest Change-Id: I960165813c260ac8f8e17cc163fabf65b1417480
* Close access to WindowGlobalManager.trimMemory starting with QSergey Vasilinets2019-02-081-1/+1
| | | | | | | | Let system decide itself when to clear internal caches. Test: N/A Change-Id: Iea72bbbdbe1a8efd23b348895b8cf522f0259e7c Fixes: 124051903
* Deprecate InputMethodManager#getInstance()Yohei Yukawa2018-09-211-5/+4
| | | | | | | | | | | | | | | | | | | | With this CL, no one in the Framework is using InputMethodManager#getInstance() directly or indirectly. It is time to mark this method deprecated. For applications that still call InputMethodManager#getInstance() directly or indirectly via reflection, they will start seeing warnings with stacktrace in logcat. Except for that explict warnings in logcat, there is no behavior change in this CL. Added a new test to make sure that InputMethodManager#getInstance() and InputMethodManager#peekInstance() are still working in a way we expected for such applications. Fix: 115891476 Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases Change-Id: Ib393086d921f91993395b5f0007b725a5db7bf22
* Let IMMS be responsible for IInputMethodClient lifecycleYohei Yukawa2018-09-191-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the last step to remove the dependency on IInputMethodClient from WindowManagerService. With my previous CL [1], now WindowManagerService (WMS) depends on IInputMethodClient just because it implements lifecycle management of IInputMethodClient on behalf of InputMethodManagerService (IMMS). This CL mechanically moves that responsibility from WMS to IMMS for better separation of concerns. It is a bit ironic that this CL is partly undoing my previous CLs [2][3] that removed IInputMethodManager.addClient() though. This CL aims to preserve the current observable behavior (e.g. when InputMethodManager instance is being created) as much as possible. Most likely there would be no observable behavior difference when seen from other components. [1]: I444077b1e4af4033f67ab72c181fac85b601e08a 41f89c3bccd0613a29a46b132891ba16032990d9 [2]: I453200fd5847e9a78876affb6a1caec221525e1d e24ed79edb937c743b96b3f9baddc689fb694be1 [3]: Id91dd600120e4981aa1d9005ce644728968430c9 fffc0e53c62614c288e9e702d69e517db17dccd7 Fix: 115993358 Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases Change-Id: I7726c70613ea72d6e78fa5754e9fc840f0a40f11
* Always use Context.getSystemService() to get IMMYohei Yukawa2018-09-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a preparation to deprecate the following two methods. * InputMethodManager#getInstance() * InputMethodManager#peekInstance() Since we soon need to stop relying on the current per-process InputMethodManager singleton model to fully support multi-display, those two methods really need to be deprecated. With this CL, framework code no longer depends on InputMethodManager#peekInstance(), which is also marked as deprecated in this CL. InputMethodManager#getInstance() is a bit tricky because it also works as a constructor of such a per-process singleton instance. Remaining two call-sites of this method will be migrated in a subsequent CL. This is a mechanical refactoring, which in theory should have no observable logical behavior difference. There could be a small performance regression, but it is basically not avoidable to correctly support multi-display scenarios. Bug: 115891476 Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases Test: atest CtsWidgetTestCases:android.widget.cts.EditTextTest Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest Test: atest FrameworksCoreTests:com.android.internal.inputmethod Test: atest FrameworksServicesTests:com.android.server.textservices Change-Id: I5db31491f3d47d3ad4a621e956995135c72e007b
* Move some members to the "Q blacklist".Mathew Inwood2018-09-141-1/+2
| | | | | | | | | | | | | | Based on some analysis, these fields/methods are likely false positives. Set maxTargetSdk=P so that any apps using them are required to migrate off them in future. See the bug for more details. Exempted-From-Owner-Approval: Automatic changes to the codebase affecting only @UnsupportedAppUsage annotations, themselves added without requiring owners approval earlier. Bug: 115609023 Test: m Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
* Add @UnsupportedAppUsage annotationsMathew Inwood2018-08-201-0/+19
| | | | | | | | | | | | | | | | | | | | | | For packages: android.view.textservice android.view.textclassifier.logging android.view.textclassifier android.view.inputmethod android.view.autofill android.view.accessibility android.view This is an automatically generated CL. See go/UnsupportedAppUsage for more details. Exempted-From-Owner-Approval: Mechanical changes to the codebase which have been approved by Android API council and announced on android-eng@ Bug: 110868826 Test: m Change-Id: I4147b038ed7adf0311ee9918b44766f82a057eaf
* Forward Activity stop signal to attached windows.Robert Carr2018-04-031-0/+4
| | | | | | | | | | | | Simply put there is nothing ensuring PopupWindow's stop using the Surface before the app is stopped. Since PopupWindow's are detached from the main View Hierarchy teardown of the main window provides no such guarantee. It seems enough to forward the "WindowStopped" signal from ViewRoot to other ViewRoot's using the token of that ViewRoot. Bug: 62536731 Test: Manual Change-Id: Ib431f49be7e06a6397a40c11ec7e842a8bc5caf9
* Fix: WindowManagerGlobal#setStoppedState failed by IOOBETetsutoki Shiozawa2017-11-081-1/+2
| | | | | | | | | | | | | | | | | Symptom: An application crashed due to IndexOutOfBoundsException. The exception was thrown at WindowManagerGlobal#setStoppedState. Root cause: setStoppedState invokes setWindowStopped for each ViewRoot by ascending order. If an application removes its view within the loop, loop index exceeds the number of items. Solution: Loop in descending order. Bug: 69018607 Change-Id: I7e20282dc99b767912be4e00d81ffb49fe6c7ac0
* Suppress a11y shortcut on emergency dialerPhil Weaver2017-02-141-2/+4
| | | | | | | | | | | Suppressing whenever the keyguard is locked, not just when it's showing. This should reduce false triggering. Bug: 34820720 Test: Verfied that shortcut no longer activates on emergency dialer or lock screen. Change-Id: Ic43c11798f04217c2871efe7d0fa21dbf61fd953
* Add content description and tooltip to menu itemVladislav Kaznacheev2017-01-051-0/+13
| | | | | | Bug: 34076597 Test: manual Change-Id: Ide32463252457721286c929ab2f8f7bae241835d
* Merge "Provide synchronization to setview to avoid NPE" am: b05b93a674 am: ↵Gopal Krishna Shukla2016-09-251-9/+6
|\ | | | | | | | | | | | | | | 810c31fdca am: 621e87d72f am: 260af96306 Change-Id: I1907b2252ae2fa25667b3a0484f6852660c74da3
| * Provide synchronization to setview to avoid NPEGopal Krishna Shukla2016-09-221-9/+6
| | | | | | | | | | | | | | | | | | | | If setView() will be called from two different threads then mView property of a View object may have inconsistent value. For instance, setView() may set mView to null causing NullPointerException. Synchronize root.setView() as well to avoid this. Change-Id: I5f9cf47ece5d4aca575bd8644ecfcee0ed43d843
* | Fix wording regarding ThreadedRendererStan Iliev2016-06-281-2/+2
|/ | | | | | | | ThreadedRenderer is not synonymous with hardware rendering, so remove references to hardware rendering when referring to ThreadedRenderer. Change-Id: Ic66a482ccf05f556ebe6ec194ce4f858f75bbb8b
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-13 12:54:03 +0000