This fixes spurious verification errors that would be generated
when a view declined an initial event such as ACTION_DOWN. Since
the view would not receive the rest of the event stream, it would
not see the corresponding ACTION_UP and the next ACTION_DOWN would
trigger a spurious verification error.
Change-Id: I2386acf378cd1765d5446faed5ad9c6525f8b400
Added a new PointerIcon API (hidden for now) for loading
pointer icons.
Fixed a starvation problem in the native Looper's sendMessage
implementation which caused new messages to be posted ahead
of old messages sent with sendMessageDelayed.
Redesigned the touch pad gestures to be defined in terms of
more fluid finger / spot movements. The objective is to reinforce
the natural mapping between fingers and spots which means there
must not be any discontinuities in spot motion relative to
the fingers.
Removed the SpotController stub and folded its responsibilities
into PointerController.
Change-Id: I5126b1e69d95252fda7f2a684c9287e239a57163
Make addHeaderView and addFooterView be more consistent with each other: they
now both check that there either is no existing adapter, or that the existing
adapter is a HeaderViewListAdapter, and they both call the DataSetObserver
(previously only addHeaderView would check the adapter, and it would only
check that it was null, while only addFooterView would call the DataSetObserver)
Make removeHeaderView and removeFooterView check that the DataSetObserver
is non-null before using it.
Change-Id: I681b87f70aabca63e664ca8d0c1cfc25530e00b9
In the old world, MenuBuilder and MenuItemImpl were responsible for
generating views for any presentation of a menu. MenuBuilder needed to
know any types and resources involved, and the implied caching
semantics did not work well for menus presented within AdapterViews.
In the new world, the MenuPresenter interface takes over the
responsibility of generating views or adapters for menu
items. MenuBuilder/MenuItemImpl still provide extra metadata tracking
used by these presenters. Mutiple presenters may be active for a
single menu at a time. All of this remains internal framework
implementation details.
BaseMenuPresenter provides a simple base for presenters that treats
the host MenuView more like an AdapterView. This allows for less
rebuilding of views when items are added/removed.
Callbacks have been restructured. Calls that relate to the menu itself
are still handled by MenuBuilder.Callback, but calls related to a
specific presentation of a menu are handled by MenuPresenter.Callback
objects attached to a MenuPresenter.
Also add API to programmatically set divider options for LinearLayout
and hidden API so that ActionBarView can have finer-grained control
over divider placement.
Change-Id: I2265b86a084279822908021aec20dfbadc1bb56b
(a) Don't check that the audiotrack is initialized (will
not be true in static mode until the first write call)
(b) Block until it completes playing.
Change-Id: I50eb6cece00f3d12f3b75102d62014c360ac0346
The FragmentManager/ListFragment impl was restoring the list
state before setting its adapter. This caused the list view to
lose the state, since it gets cleared as part of setting the
adapter. Now the fragment manager waits on restoring the view
hierarchy state until after it has done onActivityCreated(),
at which point we have set the adapter.
It would be nice to make list view less fragile in this regard,
but that is for a different change.
Change-Id: I032d6fe0fefc0dabfae95d44152146029ef5db8e
Whenever a new media button receiver is registered, save it
in the settings.
When the system audio settings are reloaded or when the
AudioService is created, the registered media button receiver
is restored.
Whenever a package is removed from the system, remove
any media button receiver from the same package that are in
the media button receiver stack. If this causes the currently
registered receiver to change (i.e. the top of the stack),
this will cause an update of the receiver stored in the
system settings.
Note that unregistering a media button receiver will not
cause the receiver saved in the settings to be updated,
this is ON PURPOSE. This is to prevent well behaved
application who unregister their receiver at the destruction
of their service, to not receive the intent after a reboot,
and to not encourage applications to never unregister
their receiver.
Change-Id: I941b777debaa56e88de93c3b03aec40331ea9ab1
- Create /data/user directory and symlink /data/user/0 -> /data/data for
backward compatibility
- Create data directories for all packages for new user
- Remove data directories when removing a user
- Create data directories for all users when a package is created
- Clear / Remove data for multiple users
- Fixed a bug in verifying the location of a system app
- pm commands for createUser and removeUser (will be disabled later)
- symlink duplicate lib directories to the original lib directory
Change-Id: Id9fdfcf0e62406a8896aa811314dfc08d5f6ed95
This adds two methods:
SynthesisRequest.getMaxBufferSize()
SynthesisRequest.completeAudioAvailable()
Change-Id: I1186eed45997ee9a7e51212c8d6706dd324ca949
This removes the old non-public C++ API for TTS
engines and replaces it with a Java API.
The new API is still @hidden, until it has been approved.
Bug: 4148636
Change-Id: I7614ff788e11f897e87052f684f1b4938d539fb7
We now write to the parcel using deltas. For common situations,
it only takes 4 bytes to write a delta (new command, time delta,
significant state changes, flags indicating additional state that
follows).
Increasing the buffer size to 128K, this give us 32,768 samples
if they all fit in the smallest delta. A device that is doing
something every minute (like acquiring a wake lock or doing a
wifi scan) for our max target battery life of 30 days would
generate 43,200 samples.
Also some turning to the maximum time between samples at which
we decide to completely collapse two samples.
Change-Id: I074a698d27ccf9389f9585abfc983af2f5ba7a54
We now write battery history directly into a buffer, instead of
creating objects. This allows for more efficient storage; later
it can be even better because we can only write deltas.
The old code is still there temporarily for validation.
Change-Id: I9707d4d8ff30855be8ebdc93bc078911040d8e0b
You can remove sub-tasks inside of a task, or an entire task.
When removing an entire task, you can have its process killed
as well.
When the process is killed, any running services will get an
onTaskRemoved() callback for them to do cleanup before their
process is killed (and the service possibly restarted).
Or they can set a new android:stopWithTask attribute to just
have the service automatically (cleanly) stopped at this point.
Change-Id: I1891bc2da006fa53b99c52f9040f1145650e6808
