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
