Also know as:
Issue #3272051 Contacts edit view: Tapping the in-app back button
results in a forward transition
Yeah more complexity in deciding which animation to use.
Also reduce complexity in deciding which app's animation set to use,
to balance things out (and make it have less stupid behavior).
Change-Id: I78c6c5c5249a96206f7e03ce587c1dcb9a7dc14f
Privileged callers can now ask the transport for a string describing
its current state, and for an Intent that can be passed to startActivity()
in order to bring up its exported configuration UI. These will be used
in Settings in order to e.g. show the user the currently active account
being used for backup, and allow the user to choose an account.
The data being funnelled through IBackupManager here are the ones
already exposed by the transports in their implementation of the
IBackupTransport interface.
Bug: 2753632
Change-Id: I2227a2b111d8d0ddf221d63020e20c1316fff55b
* Allows an app to detect that it needs to have additional policies granted
* Add "refreshing" parameter to setActiveAdmin() to handle this case
* Minor cleanups to eliminate warnings (mostly for unused things)
Bug: 3253179
Change-Id: I4bf639bf560557130bf98e8cfb75f996fac416f1
For multiple reason, this effect is not maintainable and was never
used due to its abysmal performance. it'll be resurected when it can be
implemented efficiently.
Change-Id: Id4222c9b86c629275cdec18873ef07be8723b6d2
The goal is to fix a bunch of fragment-related bugs caused by various
things trying to do fragment transactions after onPause()... which
currently throws an exception, since this is after the activity's state
has been saved so the new fragment state can be lost.
The basic change is relatively simple -- we now consider processes
hosting paused or stopping activities to be unkillable, and the client
code now does the onSaveInstanceState() as part of stopping the
activity.
For compatibility, if an app's targetSdkVersion is < HONEYCOMB, the
client side will still call onSaveInstanceState() prior to onPause()
and just hold on to that state until it needs to report it in once
being stopped.
Also included here is a change to generate thumbnails by taking
screenshots. The code for generating thumbnails by re-rendering
the view hierarchy is thus removed.
Change-Id: Iac1191646bd3cadbfe65779297795f22edf7e74a
This change enables the framework to synthesize key events to implement
default behavior when an application does not handle a key.
For example, this change enables numeric keypad keys to perform
their associated special function when numlock is off.
The application is informed that it is processing a fallback keypress
so it can choose to ignore it.
Added a new keycode for switching applications.
Added ALT key deadkeys.
New default key mappings:
- ESC -> BACK
- Meta+ESC -> HOME
- Alt+ESC -> MENU
- Meta+Space -> SEARCH
- Meta+Tab -> APP_SWITCH
Fixed some comments.
Fixed some tests.
Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
* commit '05813b0eb92cb1bc79607ee402f14ca1e4b43f6d':
[3253328, 3171580] Treat GONE and INVISIBLE views the same when calculating transparent regions
[3171580] Fix two typos related to fixed-size buffers
Added CMD_SET_DATA_ENABLE which is sent when data is enabled/disabled
via the ConnectivityService. It is anticipated that the communication
channel will be used for additional commands and to receive unsoliciated
commands from DataConnectionTracker back to MobileDataStateTracker.
Change-Id: I3863e7385155d503f069b1dcb7e4f766ec78b5f8
mFixedSize was never set, this bug was introduced during some "cleanup", in
practice this could cause some issues when a fixed-size buffer was used and
the window was resized.
Layer::drawForSreenShot() had a typo that had no effect.
mFixedSize was used to determine if filtering was needed, which was a bit too
conservative and created a dependency between filtering and "fixed size" states
which should exist.
Now we enable filtering based on the size of the buffer vs. the size of the layer.
Change-Id: I32044e91b0c944c1b137efdceb3f01dfaa78119d
some of these failures are not fatal and even expected in some cases
so they should not emit a dump in the log in those cases.
Change-Id: Idcfa252e3bfa9d74e27fe4ad8f8623aa01aa9c5e
Use Vendor ID, Product ID and optionally the Version to
locate keymaps and configuration files for external devices.
Moved virtual key definition parsing to native code so that
EventHub can identify touch screens with virtual keys and load
the appropriate key layout file.
Cleaned up a lot of old code in EventHub.
Fixed a regression in ViewRoot's fallback event handling.
Fixed a minor bug in FileMap that caused it to try to munmap
or close invalid handled when released if the attempt to map
the file failed.
Added a couple of new String8 conveniences for formatting strings.
Modified Tokenizer to fall back to open+read when mmap fails since
we can't mmap sysfs files as needed to open the virtual key
definition files in /sys/board_properties/.
Change-Id: I6ca5e5f9547619fd082ddac47e87ce185da69ee6
This patch allows users of WindowManagerService.injectKeyEvent() to
set flags on the key event being injected.
In particular this allows long presses (FLAG_LONG_PRESS) to be
injected into the window manager.
By returning the channel object it self it is unnecessary
to have a token. Also, no current code needed it, if its
needed in the future it can be added back.
Change-Id: Ie1d2a1e885f9cd74e95663711ccefb760811bf16
When calling startDrag(), the app can now supply an Object to be passed
along in every DragEvent that the app winds up receiving itself. This
object is *not* passed to any other applications; it's strictly app-
local. The purpose is to allow state tracking/management to be done
directly through the drag mechanism rather than requiring out-of-band
code.
An example of the utility here might be TextEdit widgets. A drag that
starts in one TextEdit but ends in a different one should be treated as
a copy/paste operation, where the originating TextEdit is not altered.
However, a drag that starts and ends in the *same* TextEdit is a 'move'
operation within that TextEdit; the text is removed from its original
position and inserted at the drop point. To support this easily, the
drag/drop code in TextEdit can now pass a pointer to the originating
view as the local state object. Then, the drop recipient could tell
whether the drag started within the same TextEdit without needing to
implement any other out-of-band state tracking.
This CL (and its accompanying CLs in a few other packages where the
startDrag() API is being used) adds the new local-state parameter to
the API, but does not actually change the behavior of any existing
clients.
Change-Id: Icba73b2ab4a650b7a94485a19633065b0ef9058c
The problem is that the code in AudioPolicyManagerBase::checkAndSetVolume() that forces
voice volume to max when setting bluetooth SCO volume is not called if the bluetooth stream
volume did not actually change. So even if we re apply volumes when switching to bluetooth
device, the volume voice volume is not changed and remains what it was when routed to earpiece
What makes things worse on Passion is that stream volumes are limited when connected to bluetooth
and their actual value does not change as soon as they exceed the limit threshold.
Change-Id: Id7c317db45b392a1c20dca2859678e3c64a371ed
