Added support for mapping both scan codes and HID usages to
KeyLayoutMap and KeyCharacterMap. Keyboard overlays can
now influence how key events are mapped to key codes.
Bug: 6110399
Change-Id: I6619fd2d3e1337c55928f89869dbc45b535c7ccf
Added the concept of a keyboard layout overlay, which is
a key character map file that has "type OVERLAY".
Added support for loading keyboard layout overlays from
resources dynamically. The layouts are reloaded whenever they
are changed in the Settings application or an application
is installed. This is somewhat more aggressive than necessary
so we might want to optimize it later.
Before system-ready, the input system uses just the generic
keyboard layouts that are included on the device system image.
After system-ready, it considers the user's selected keyboard
layout overlay and attempts to load it as necessary. We need to
wait until system-ready before doing this because we need to
be in a state where it is safe to start applications or access
their resources.
Bug: 6110399
Change-Id: Iae0886d3356649b0d2440aa00910a888cedd8323
Added two public methods to Debug. These methods return a String
indicating the caller (getCaller()) or callers (getCallers(int depth))
of the calling method. The String indicates the class, method and line
number of the caller(s). Similar to using Throwable.fillInStackTrace()
but much more concise.
Change-Id: I53d0085aa50e4501d28e8eb3ad5b91ef700ac218
Several Surface operations - notably setPosition, setSize, and show -
had been moved outside of a Surface.openTransaction/closeTransaction
window. This corrects that problem.
In addition, before animations were separated from layout the Surface
frame was computed prior to returning from relayoutWindow(). After
separation the frame was being computed during animation. This checkin
restores the frame calculation in layout.
Fixes bug 6343291.
Change-Id: I4752bdf1fed0f2b46c5eb9508825c9b1b0fd702f
An intent is launched in a singleton process if the process is persistent
and the resolved activity/service/etc is not requested to run in a different
process.
Change-Id: I1463e73a76bc8bde4185f9cf4395edb47515841d
In the old code orientationChangeComplete was set to true on each pass
through perfomLayout. If any window was rotating the variable was set
to false on the way through the performLayout. Since we can now make
passes through performLayout before any animation step occurs we were
seeing mOrientationChangeComplete true prior to rotation completing.
This change sets mOrientationChangeComplete false at the start of a
rotation and sets it to true if we ever get through an animation step
without encountering any rotating windows.
Change-Id: I37690cf20868dfbaac94a81640bc4d9cb9fb8f00
Changed the SensorManager class so that it only contains API-related
bits including what's needed to support legacy sensors. Mostly just
moved stuff around. Making the class abstract is safe because
it does not have a visible constructor in the API.
One minor change is that the cache of sensor type to sensor lists
is now per instance of SensorManager instead of being static.
We can fix this if desired.
Another small change is that we bail out early from registerListener
if the listener has already been registered for the particular
sensor. This happened for both legacy and standard listeners.
The problem is that the ListenerDelegate maintains two lists of
sensors, one is a Map and the other is a List. Adding a sensor
twice causes one entry to be added to the Map and two entries to be
added to the List, but when the sensor is removed the next time, only
one entry is removed from the List, leaving it in an inconsistent
state.
Removed Sensor.getLegacyType() since the value it provides is only
needed in LegacyListener and we don't really save any significant
computation by caching it. Removing the field makes support for
legacy sensors a little more self-contained.
Bug: 6339552
Change-Id: I50d41ac97cf535924f2bfa2026d28547a4d00286
Report to developers if active network is "metered" and define it
as the user being sensitive to heavy data usage.
Bug: 3001465
Change-Id: I855ca3cd3eb1de3c4814148d70ccf24957af898a
Before, RecognitionManagerService just cleared the recognizer
setting, which the Settings app really doesn't like.
Bug: 6332933
Change-Id: If4f9b583c304c5ea99021dddda50fca55e3ac541
Add support for DNS based network service discovery API. This
allows applications to discover and resolve applications on a
local network such as Wi-Fi
Change-Id: Ie89895edd35d12b7f7a23fb5fed36cb2b2079f7a
Forward-locked apps aren't very prevalent, but it needed to be
restructured to make sure both streams and ZipFile objects are closed.
Change-Id: I41f863224fecd24069e525e9ce3738de8237bd5e
It's difficult to see in bugreports when this situation arises. Add a
small log so we can easily determine installation failure reason.
Change-Id: Ie59c205cf731cad7b3d04ceb995e58a093c62455
Animation steps are now executed on a Thread launched from the
Choreographer rather than being called at the end of the WindowManager
layout process. Animations and layout are still tightly coupled in
that they share considerable state information and neither can be
executed without holding a lock on WindowServiceManager.mWindowMap.
Change-Id: Ie17d693706971507b50aa473da1b7258e9e67764
Usefulness: Keep track of the current user location in the screen when
traversing the it. Enabling structural and directional
navigation over all elements on the screen. This enables
blind users that know the application layout to efficiently
locate desired elements as opposed to try touch exploring the
region where the the element should be - very tedious.
Rationale: There are two ways to implement accessibility focus One is
to let accessibility services keep track of it since they
have access to the screen content, and another to let the view
hierarchy keep track of it. While the first approach would
require almost no work on our part it poses several challenges
which make it a sub-optimal choice. Having the accessibility focus
in the accessibility service would require that service to scrape
the window content every time it changes to sync the view tree
state and the accessibility focus location. Pretty much the service
will have to keep an off screen model of the screen content. This
could be quite challenging to get right and would incur performance
cost for the multiple IPCs to repeatedly fetch the screen content.
Further, keeping virtual accessibility focus (i.e. in the service)
would require sync of the input and accessibility focus. This could
be challenging to implement right as well. Also, having an unlimited
number of accessibility services we cannot guarantee that they will
have a proper implementation, if any, to allow users to perform structural
navigation of the screen content. Assuming two accessibility
services implement structural navigation via accessibility focus,
there is not guarantee that they will behave similarly by default,
i.e. provide some standard way to navigate the screen content.
Also feedback from experienced accessibility researchers, specifically
T.V Raman, provides evidence that having virtual accessibility focus
creates many issues and it is very hard to get right.
Therefore, keeping accessibility focus in the system will avoid
keeping an off-screen model in accessibility services, it will always
be in sync with the state of the view hierarchy and the input focus.
Also this will allow having a default behavior for traversing the
screen via this accessibility focus that is consistent in all
accessibility services. We provide accessibility services with APIs to
override this behavior but all of them will perform screen traversal
in a consistent way by default.
Behavior: If accessibility is enabled the accessibility focus is the leading one
and the input follows it. Putting accessibility focus on a view moves
the input focus there. Clearing the accessibility focus of a view, clears
the input focus of this view. If accessibility focus is on a view that
cannot take input focus, then no other view should have input focus.
In accessibility mode we initially give accessibility focus to the topmost
view and no view has input focus. This ensures consistent behavior accross
all apps. Note that accessibility focus can move hierarchically in the
view tree and having it at the root is better than putting it where the
input focus would be - at the first input focusable which could be at
an arbitrary depth in the view tree. By default not all views are reported
for accessibility, only the important ones. A view may be explicitly labeled
as important or not for accessibility, or the system determines which one
is such - default. Important views for accessibility are all views that are
not dumb layout managers used only to arrange their chidren. Since the same
content arrangement can be obtained via different combintation of layout
managers, such managers cannot be used to reliably determine the application
structure. For example, a user should see a list as a list view with several
list items and each list item as a text view and a button as opposed to seeing
all the layout managers used to arrange the list item's content.
By default only important for accessibility views are regared for accessibility
purposes. View not regarded for accessibility neither fire accessibility events,
nor are reported being on the screen. An accessibility service may request the
system to regard all views. If the target SDK of an accessibility services is
less than JellyBean, then all views are regarded for accessibility.
Note that an accessibility service that requires all view to be ragarded for
accessibility may put accessibility focus on any view. Hence, it may implement
any navigational paradigm if desired. Especially considering the fact that
the system is detecting some standard gestures and delegates their processing
to an accessibility service. The default implementation of an accessibility
services performs the defualt navigation.
bug:5932640
bug:5605641
Change-Id: Ieac461d480579d706a847b9325720cb254736ebe
Added a getVibrator() method to InputDevice which returns a Vibrator
associated with that input device. Its uses the same API as the
system vibrator which makes it easy for applications to be modified
to use one or the other.
Bug: 6334179
Change-Id: Ifc7f13dbcb778670f3f1c07ccc562334e6109d2e
- Replace HashSet with ArrayList.
- Check for Watermark and SurfaceSession initialization once, not every
time through layout.
- Move watermark rendering into animation.
- Add surface operation debugging.
Change-Id: I4b7e7c0b8d89d43c67a42753832f90b8632d4f5d
Moved the core logic of Vibrator into SystemVibrator, potentially
allowing for the creation of other Vibrator subclasses.
Fixed several places where we were creating new Vibrator
instances unnecessarily instead of getting it from the Context.
It is safe to make Vibrator abstract because its constructor
was hidden from the SDK so it was not possible to subclass it.
Bug: 6334179
Change-Id: I18ece6544c26a7efb2d5099f8346a10aef8a5e18
Enable default enforcement of READ_EXTERNAL_STORAGE on non-user
builds. Users can still explicitly enable enforcement in Settings.
Bug: 6131916
Change-Id: I7dc66b624ad252ed2a2ad3647f3ea85dda7f8e82
