These pragma statements used to guard against compiler warnings in Sk..
code. They are no longer necessary.
Test: make
Change-Id: I9f7f88276edb546ba08c7344c142eb487a04f978
The loop as constructed causes i to overflow twice when i = 0 on integer
overflow sanitized builds.
runtime error: unsigned integer overflow: 0 - 1 cannot be represented
in type 'size_t' (aka 'unsigned long')
runtime error: unsigned integer overflow: 18446744073709551615 + 1
cannot be represented in type 'size_t' (aka 'unsigned long')
This refactors the loop to avoid the overflows.
Bug: 30969751
Test: Compiles, device boots, enabled pointer location overlay.
Change-Id: I844bb3b84b1f536c50d06fb489fcc22590d4aa98
Currently PointerController starts listening to display events
immediately (in its constructor) and never explicitly removes
the callback. The reference dangling from the looper
prevents the PointerController instance from being deleted
when all the clients have released their references.
As a result, when USB or BT mouse is disconnected,
the mouse stays frozen on screen and only goes away
after a 15 sec inactivity timeout.
This change introduces an intermediary LooperCallback
which holds only a weak reference to PointerController.
The pointer now disappears immediately upon mouse
disconnect.
Bug: 30824220
Change-Id: I5f7208dbfa381b3e21f248cc0da402f307faa184
The underlying implementation needs to be completely rethought. If a
process crashed while you were in pointer capture mode, you were
pretty much stuck in it. If the mouse happened to move outside of
your bounds right before you called the API, you'd never actually get
an event (whatever it was hovering over would). There's no easy way
for the system to tell you when you enter or exit this mode because
it doesn't actually track who the current request is from.
These are all solvable, but not in the N time frame. Maybe next time.
Bug: 26830970
Change-Id: I899649594c7ca8db5962fcdaa71c5b21d3aa42c3
The underlying implementation needs to be completely rethought. If a
process crashed while you were in pointer capture mode, you were
pretty much stuck in it. If the mouse happened to move outside of
your bounds right before you called the API, you'd never actually get
an event (whatever it was hovering over would). There's no easy way
for the system to tell you when you enter or exit this mode because
it doesn't actually track who the current request is from.
These are all solvable, but not in the N time frame. Maybe next time.
Bug: 26830970
Change-Id: I03efd63c499b86dc278491ca3284566c1965581f
This patch does the following things:
- add new graphic assets of large icons for accessibility needs
(imported from ChromeOS data)
- add the logic to choose the set of normal icons or accessibility icons
- make InputManagerService to observe the settings change, so that
it can reload the new resources
This patch misses non-1x graphic though, because ChromeOS doesn't
have such data.
Bug: 25778857
Change-Id: Ia5f95d47f50b3f6eea555c3af8069bc6bae0b400
Right now, it only supports I-beam on EditText, but further
rules will come in the future.
The png files for the icons are from chromium.
Bug: 24180385
Change-Id: I8de4ec8a5412b4830c08aa232c5083841c5c751c
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
