18a23f2fd8c18d812401563e1d9a847e4c2a2d93 |
|
06-Apr-2017 |
Amith Yamasani <yamasani@google.com> |
Log excessive remote callbacks Bug: 36778087 Test: N/A Change-Id: Ifb02fe09e3c0869f7f6c741f886421064e5c1b8a
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
ef4351cc72abeeba0f659950c199a4f9b7cd1842 |
|
18-Jan-2017 |
Eugene Susla <eugenesusla@google.com> |
Dont dispatch a11y events that have no subscribers This allows to avoid A11yManager -> A11yManagerService IPC, when there's no subscribers to a given event Test: steps: - Enable A11yManager.DEBUG - Navigate through a few random activities - In logcat, ensure log messages are present, notifying that certain events won't be dispatched Change-Id: Ia019fb66053f10095b3651407d09de8e89cdd227
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
59359d06c4b504579db1bc72ded5ef29c4334c79 |
|
04-Mar-2017 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #35813031: API Review: RemoteCallbackList Review comments addressed: - Docs fixed. - getRegisteredCallbackItem() added. Test: booted system Change-Id: Ib5228c566eedc5dcf72933bb375eba4257293cfc
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
5614bf5a1ae4522dfc1a041f003cebc9b25c8b93 |
|
08-Nov-2016 |
Dianne Hackborn <hackbod@google.com> |
Move code for handling uid obs "cutoff" to activity manager To do this, I had to fix the PROCESS_STATE_NONEXISTENT constant to be the last value (instead of the special magical -1 value) so it semantically matches the public importance constants. I think this is better anyway. Also this fixes a big problem in the implementation, where we weren't keeping track of the last proc state per uid...! Duh. Test: manually ran testUidImportanceListener Change-Id: Ie3008f824446089840f896885e6033472abb065e
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
7bdb9ce97811782864d3b54616f233c041590c7e |
|
15-Sep-2016 |
Makoto Onuki <omakoto@google.com> |
Fix system crash due to mismatching begin/finishBroadcast() Bug 31449363 Change-Id: I514196355a2566c5e4f7f3af91fbf3c57cb67a48
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
f7c06eb03ab4479b9d0656a23a4733d17e995183 |
|
11-Jun-2015 |
Svetoslav <svetoslavganov@google.com> |
Add system API to watch for permission changes Change-Id: I1ce450a59fb326c14848f46732d877dea33f33c7
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
44720af55a8fdf991929983dad5d53c02851dd1e |
|
21-Aug-2013 |
Svetoslav Ganov <svetoslavganov@google.com> |
Print UI bug fixing and printer discovery refactoring. 1. Added support for selecting a printer from the all printers activity that is not in the initial printer selection drop down. The user initially sees a sub set of the printers in the drop down and the last option is to see all printers in a separate activity. Some of the printers in the all printers activity are not shown in the initial drop down. 2. Refactored printer discovery by adding (private for now) printer discovery app facing APIs. These APIs are needed to support multiple printer selection activities (print dialog and all printers activities) and also the settings for showing all printers for a service. Now multiple apps can request observing for printers and there is a centralized mediator that ensures the same printer discovery session is used. The mediator dispatches printer discovery specific requests to print services. It also aggregates discovered printers and delivers them to the interested apps. The mediator minimizes printer discovery session creation and starting and stopping discovery by sharing the same discovery session and discovery window with multiple apps. Lastly, the mediator takes care of print services enabled during discovery by bringing them up to the current discovery state (create discovery session and start discovery if needed). The mediator also reports disappearing of the printers of a service removed during discovery and notifies a newly registered observers for the currnet printers if the observers are added during an active printer discovery session. 3. Fixed bugs in the print UI and implemented some UX tweaks. Change-Id: I4d0b0c5a6c6f1809b2ba5dbc8e9d63ab3d48f1ef
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
390517be2d60dd6e6264150c190c372d89bb331a |
|
31-May-2013 |
Dianne Hackborn <hackbod@google.com> |
Clean up some temporary allocations. Yay to ArrayMap, letting me get rid of a bunch of temporary iterators in core code paths like updateOomAdj. (Now I definitely need an ArraySet to finish that up.) Also clean up various other things that are doing unnecessary allocations, clean up some debug output, make more of the debug output respect package filtering. Change-Id: Ib4979faf4de8c7912739bc0937c3fa9e7bfcde67
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
1cf70bbf96930662cab0e699d70b62865766ff52 |
|
06-Aug-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Screen magnification - feature - framework. This change is the initial check in of the screen magnification feature. This feature enables magnification of the screen via global gestures (assuming it has been enabled from settings) to allow a low vision user to efficiently use an Android device. Interaction model: 1. Triple tap toggles permanent screen magnification which is magnifying the area around the location of the triple tap. One can think of the location of the triple tap as the center of the magnified viewport. For example, a triple tap when not magnified would magnify the screen and leave it in a magnified state. A triple tapping when magnified would clear magnification and leave the screen in a not magnified state. 2. Triple tap and hold would magnify the screen if not magnified and enable viewport dragging mode until the finger goes up. One can think of this mode as a way to move the magnified viewport since the area around the moving finger will be magnified to fit the screen. For example, if the screen was not magnified and the user triple taps and holds the screen would magnify and the viewport will follow the user's finger. When the finger goes up the screen will clear zoom out. If the same user interaction is performed when the screen is magnified, the viewport movement will be the same but when the finger goes up the screen will stay magnified. In other words, the initial magnified state is sticky. 3. Pinching with any number of additional fingers when viewport dragging is enabled, i.e. the user triple tapped and holds, would adjust the magnification scale which will become the current default magnification scale. The next time the user magnifies the same magnification scale would be used. 4. When in a permanent magnified state the user can use two or more fingers to pan the viewport. Note that in this mode the content is panned as opposed to the viewport dragging mode in which the viewport is moved. 5. When in a permanent magnified state the user can use three or more fingers to change the magnification scale which will become the current default magnification scale. The next time the user magnifies the same magnification scale would be used. 6. The magnification scale will be persisted in settings and in the cloud. Note: Since two fingers are used to pan the content in a permanently magnified state no other two finger gestures in touch exploration or applications will work unless the uses zooms out to normal state where all gestures works as expected. This is an intentional tradeoff to allow efficient panning since in a permanently magnified state this would be the dominant action to be performed. Design: 1. The window manager exposes APIs for setting accessibility transformation which is a scale and offsets for X and Y axis. The window manager queries the window policy for which windows will not be magnified. For example, the IME windows and the navigation bar are not magnified including windows that are attached to them. 2. The accessibility features such a screen magnification and touch exploration are now impemented as a sequence of transformations on the event stream. The accessibility manager service may request each of these features or both. The behavior of the features is not changed based on the fact that another one is enabled. 3. The screen magnifier keeps a viewport of the content that is magnified which is surrounded by a glow in a magnified state. Interactions outside of the viewport are delegated directly to the application without interpretation. For example, a triple tap on the letter 'a' of the IME would type three letters instead of toggling magnified state. The viewport is updated on screen rotation and on window transitions. For example, when the IME pops up the viewport shrinks. 4. The glow around the viewport is implemented as a special type of window that does not take input focus, cannot be touched, is laid out in the screen coordiates with width and height matching these of the screen. When the magnified region changes the root view of the window draws the hightlight but the size of the window does not change - unless a rotation happens. All changes in the viewport size or showing or hiding it are animated. 5. The viewport is encapsulated in a class that knows how to show, hide, and resize the viewport - potentially animating that. This class uses the new animation framework for animations. 6. The magnification is handled by a magnification controller that keeps track of the current trnasformation to be applied to the screen content and the desired such. If these two are not the same it is responsibility of the magnification controller to reconcile them by potentially animating the transition from one to the other. 7. A dipslay content observer wathces for winodw transitions, screen rotations, and when a rectange on the screen has been reqeusted. This class is responsible for handling interesting state changes such as changing the viewport bounds on IME pop up or screen rotation, panning the content to make a requested rectangle visible on the screen, etc. 8. To implement viewport updates the window manger was updated with APIs to watch for window transitions and when a rectangle has been requested on the screen. These APIs are protected by a signature level permission. Also a parcelable and poolable window info class has been added with APIs for getting the window info given the window token. This enables getting some useful information about a window. There APIs are also signature protected. bug:6795382 Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
dace230043314d6fab1c5ced4b031eaccd814c25 |
|
14-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
resolved conflicts for merge of b06ea706 to master
|
b06ea706530e6d19eb2a1a9a7ae6c5dd77d80af0 |
|
13-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Add reporting of activity movement for search manager. This adds a new API with the activity manager to find out about movement between activities. For my sanity, the old IActivityWatcher is now renamed to IActivityController, and the new activity movement interface is named IActivityWatcher. This changes the search manager itself to use the new API to manage its state. Note that there are still problems when going back to the search dialog after it was hidden -- the suggestions window no longer appears until you explicitly dismiss and re-show it.
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
7a1355950172b7a549820e9a2cd4a9b2099ec32f |
|
06-May-2009 |
Dianne Hackborn <hackbod@google.com> |
merged 231cc608d06ffc31c24bf8aa8c8275bdd2636581
|
231cc608d06ffc31c24bf8aa8c8275bdd2636581 |
|
28-Apr-2009 |
Dianne Hackborn <hackbod@google.com> |
Rewrite SyncStorageEngine to use flat files and in-memory data structures. The previous implementation used a database for storing all of its state, which could cause a significant amount of IO activity as its tables were updated through the stages of a sync. This new implementation replaces that in-memory data structures, with hand-written code for writing them to persistent storage. There are now 4 files associated with this class, holding various pieces of its state that should be consistent. These are everything from a main XML file of account information that must always be retained, to a binary file of per-day statistics that can be thrown away at any time. Writes of these files as scheduled at various times based on their importance of the frequency at which they change. Because the database no longer exists, there needs to be a new explicit interface for interacting with the sync manager database. This is provided by new APIs on IContentService, with a hidden method on ContentResolver to retrieve the IContentService so that various system entities can use it. Other changes in other projects are required to update to the new API. The goal here is to have as little an impact on the code and functionality outside of SyncStorageEngine, though due to the necessary change in API it is still somewhat extensive.
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
7b0b1ed979aa665175bf3952c8902ce13c763ab8 |
|
19-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import //branches/master/...@140412
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
105925376f8d0f6b318c9938c7b83ef7fef094da |
|
19-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake_rel/...@140373
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/os/RemoteCallbackList.java
|