Collect UID-granularity network stats during regular poll event. Add
dumpsys argument to generate fake historical data for debugging, and
move stats parameters to Settings.Secure.
Change-Id: I09b36a2955dc10c697d4b9c3ff23dcb3ac37bd70
DNS based techniques dont always work. Some hotspots
redirect on data fetch on IP. Use a known pattern match
on URL to detect a walled garden instead.
Also, added gservices capability to turn off the feature
or change the URL & the pattern to match
Bug: 4378442
Change-Id: I78b4208d3ea3ace20069169e7c01ed769892d94d
Events.lastSynced: flag marking this as a duplicate of the lastSynced sate of the event
Events.sync_data7: General purpose sync column (will be used for editUrl in Google Sync Adapter)
Calendars.canPartiallyUpdate: Flag indicating sync adapter can perform partial updates.
Change-Id: I5c153fb9cbf43dd1def0267c2f912a59038b28c1
Added comments. Made internal only stuff private. Added @hide to
methods only used by the provider. Added/altered methods for
consistency across contract classes.
Change-Id: I4d810995042583f1ab05b859f320828f83329e90
A Dream is an activity that is launched by the window
manager after a specified idle time. You might think of this
as a "screen saver", but with the same capacity for
interactivity as any other application.
The window manager maintains a timer (like the screen lock
timer) that is reset on userActivity; the timer is suspended
during wakelocks and when the screen is off.
When the timer elapses, the user's preferred dream module is
launched (by reading Settings.Secure.DREAM_COMPONENT, which
is configured through the Settings app UI).
Like a dock app, the user can install new dreams and a
single application package may contain multiple dream
activities. Unlike the dock mode, however, there is no
"screensaver mode" for the system to manage. This allows us
to offer the user the ability to run a dream at any time, in
addition to making the overall mechanism quite simple.
There is no public API for this facility.
There is, however, a useful/recommended base class for dream
activities in the support library (change I4559a958).
Change-Id: Ied691856f88cfa38a7aca496d015f9a595da72f2
This column doesn't actually exist in the corresponding table, and
never has, so the presence of this definition is confusing.
Change-Id: I199f9a8effbdc9f45d51060830e3ad83675a0dff
- MTP support for multiple storage units
- Add storage_id column to media database for MTP storage ID
- Add framework resource for defining mount points and user visible descriptions
for multiple volumes
- Clean up locking in MtpServer JNI code
Change-Id: I53d501fd4891ebe27408135fb598027e06b7e495
Signed-off-by: Mike Lockwood <lockwood@android.com>
- MTP support for multiple storage units
- Add storage_id column to media database for MTP storage ID
- Add framework resource for defining mount points and user visible descriptions
for multiple volumes
- Clean up locking in MtpServer JNI code
Change-Id: Ide6d47bd9aa1698ed2a13d695613e03f2a9b29e3
Signed-off-by: Mike Lockwood <lockwood@android.com>
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
It is intentional to not use "primary_account_name" and
"primary_account_type" here. See Issue 3510087 and 4260119
Bug: 3510087
Bug: 4260119
Change-Id: I2a22be56822226e3ea6b6f2ef23bb77816d0345a
Also, allow scan interval for framework and supplicant
to be configured at build time or run time
Bug: 4144882
Change-Id: I877f4bcc872597b44d3f4da85cf2bc0f16e09444
- MTP support for multiple storage units
- Add storage_id column to media database for MTP storage ID
- Add framework resource for defining mount points and user visible descriptions
for multiple volumes
- Clean up locking in MtpServer JNI code
Change-Id: Iffb66ed156ef5bc80b14228af78fbacee7734360
This reverts commit eca208fae6
and is the first of the LTE commits in master being back ported
to the LTE branch.
Change-Id: I17d4a1b779ed74bc7dfb409d2c1a30f60fdb27c7
bug:3505060
Since we want to have some settings that are used very frequently
by many applications (long-press timeout is one example) these should
be managed efficiently to reduce lookups from different processes
because in the case of a cache miss a disk I/O is performed. Now
the system manages such core settings and propagates them to the
application processes.
Change-Id: Ie793211baf8770f2181ac8ba9d7c2609dfaa32a7
