-> This is a good change to the widget framework that I've wanted to
make for a while, but issue 7174198 triggered the immediate need.
Change-Id: I3f267e0e67f2d9f28920bb53973af365a3c9e0ba
Settings.Global namespace. Also run as a system app, since only system
apps can change airplane mode.
Change-Id: I317f9c94361cfca182356fd292e5b0b41553d1ab
Views were being kicked off when RecentsTaskLoader was being started
from BaseStatusBar.toggleRecentsActivity. Then RecentTasksLoader called
RecentsPanelView.onTasksLoaded which invalidated the Adapter and loaded
the item views. All this before window manager had determined that the
Activity should be rotated and providing a new Configuration.
This fix waits for the Activity to resume before allowing the Adapter
to be invalidated.
Fixes bug 7138698.
Change-Id: I0df67ff2e07a0e0b69cc3b52e9843f90ce763704
New APIs let you indicate what user(s) to monitor, and tell you
what user is changing when receiving a callback.
Fix package manager to only deliver package brpadcasts to the
running users. (This isn't really a change in behavior, since
the activity manager would not deliver to stopped users anyway).
Make sure all broadcasts that package monitor receives also include
user information for it to use.
Update wallpaper service to (hopefully) now Really Correctly
monitor package changes per user.
Change-Id: Idd952dd274abcaeab452277d9160d1ae62919aa0
Content observers are registered under the calling user's identity,
not under the provider host's identity (unless the caller is using
the new permissioned entry points that allow observers to be
registered for a different user's view of the data). The most important
implication of this is that when the settings provider is directly
queried, the Cursor returned to the app is wired for change notifications
based on that calling app's user.
Note that it is not possible to use query() / insert() to read/write
data for different users. All such manipulations should use the
standard get* / put* methods in Settings.*.
Bug 7122169
Change-Id: If5d9ec44927e5e56e4e7635438f4ef48a5430986
The code in onMeasure that attempts to accommodate changing
child boundaries (i.e. an expanding/collapsing notification)
was locking the window size to the child measurement, even
though another window was trying to seesaw it closed. We now
only activate the rubberband behavior when the size of the
children changes, not on each onMeasure().
Lots of other small fixes to the panel expansion logic, too,
including ensuring that the expanded fraction doesn't jump
to 1.0f when the panel content hasn't been laid out yet
(causing the entire screen to become dim for a second thanks
to PhoneStatusBarView.panelExpansionChanged).
This change also restores the ability of Binder clients
(such as accessibility systems) to expand and collapse the
status bar.
Bug: 7008196
Bug: 6995518
Bug: 6628429
Change-Id: Ib0244a27aef2b4dbe19be98f7e039a9d38f1b80e
* commit '3d5be42eaa35914d9b37fe052fa7222dc1992dc0':
Fix formatDateRange month names for Farsi.
Use localized digits for Time formatting.
Use proper digits in formatElapsedTime and format3339
