Merge commit 'ea5c044412f6853d686e93b8bef07f4729b6ad26'
* commit 'ea5c044412f6853d686e93b8bef07f4729b6ad26':
When apps switch between system and data partition the code and
Apparently this code was not 100% correct, and now the Wifi driver is responsible
for setting the scan mode to active for hidden networks, so this is no longer needed.
Signed-off-by: Mike Lockwood <lockwood@android.com>
This is the problem where various things are listening for broadcasts
(such as battery status, PIN/PUK/Network) that an application can send
to cause harm to the system.
Solving this is tricky because many of these broadcasts are sticky,
and I have never figured out how to do permissions with sticky
broadcasts in a sane way. So instead, I am going to punt on the
general problem and just brute force it:
There is new a way for system components to declare specific
broadcast actions to be protected, which means that only the system
and the phone can send them. This is good enough for now. None
of it is exposed in the public API so we can make something a little
less stupid in the future if we ever need to.
Merge commit '463aacfbd220c9ef2f6ed915d54092289fdac05b'
* commit '463aacfbd220c9ef2f6ed915d54092289fdac05b':
wifi: WifiManager.startScan() will now do passive scans by default.
Active scans will only happen if a hidden AP is in use, or if the new method
WifiManager.startScanActive() is called.
This fixes some audio playback problems with bluetooth A2DP.
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit 'ed7603779282d416356ce3c9739056d632307275'
* commit 'ed7603779282d416356ce3c9739056d632307275':
Add a persistent system property to disable the adb notification.
Setting to persist.adb.notify to 0 will disable the ad notification.
You need to be root to set this, so this allows disabling the notification
only on eng and userdebug builds.
Signed-off-by: Mike Lockwood <lockwood@android.com>
This adds a new <path-permission> tag you can use inside of a <provide>
to define additional path-based permissions that broaden the global
read and write permissions. The initial use for this will be global
search, so that a content provider that is protected by permissions
can make a part of itself available to global search under another
permission. This addresses the issue with global search not being able
to request permissions it would need of providers it doesn't know
about at build time.
Merge commit '4af0a709ee08e8ae43f49d8fc5c9cae142aaf2c4'
* commit '4af0a709ee08e8ae43f49d8fc5c9cae142aaf2c4':
Make it so the notification manager doesn't mysteriously
Merge commit '1ecf5d28817f0a051e77488380dcd5bc622ea169'
* commit '1ecf5d28817f0a051e77488380dcd5bc622ea169':
Re-implementation of large screen support using window manager.
* added background filler surface to fill the outer rim. Using the same layer as dim surface because
they never co-exists (in the same window)
* clean up the obsolete code in CompatibiltyMode/ViewRoot for support large screen support.
Merge commit '1bd3e0fb7e87f1daa983d06bc396393a788181b0'
* commit '1bd3e0fb7e87f1daa983d06bc396393a788181b0':
Don't invoke the transport if doBackup supplied no data
If there's no data to be backed up, we no longer invoke the transport. We *DO*
still require that the agent have emitted a valid new state file, however.
This change also finally uncomments the code that removes the backup data file
after it has been sent to the transport, so there will be no more
packagename.data files lying around in the staging area.
We now log in dataChanged() only when an app is added to the backup set (and
*not* if it redundantly asks to be added after it's already there) and on error.
Merge commit 'a7de3845507b7bf57a2c7b26fb08f05b193697d6'
* commit 'a7de3845507b7bf57a2c7b26fb08f05b193697d6':
Only write to the pending-backup journal when necessary
We now only commit to the pending-backup journal on disk the first time that a
given package is added to the backup set. This avoids a lot of write thrashing
of the disk, particularly since Settings tends to call dataChanged() a great
many times during boot, while the Settings UI is in use, etc.
Merge commit 'c4cf22e82ba8ec4eec7051ae3a8eb397ded578d1'
* commit 'c4cf22e82ba8ec4eec7051ae3a8eb397ded578d1':
Fix the metadata-available test during restore
Merge commit 'fa6c7111fe58e09a92741c7655221c3629d3220e'
* commit 'fa6c7111fe58e09a92741c7655221c3629d3220e':
WifiService: use wifi association state to determine if we should suspend wifi instead of
Merge commit 'dbee95cacff9d2faf30638e64abe26fbeb128787'
* commit 'dbee95cacff9d2faf30638e64abe26fbeb128787':
Make enable/provisioning of the backup service a two-step process
This CL adds the concept of 'provisioned' to the backup manager. No backups
will be scheduled until the user has indicated that backups are to be enabled
*and* has clicked all the way through the setup wizard.
When the user first turns on the backup system, the delay before the initial
backup pass is different from the periodic backup interval. Currently that
initial delay is 12 hours. The intent here is to guess at a less-active time
for performing that first backup pass.
NOTE: currently the backup service defaults to 'provisioned'. Once the real
code goes live in Setup Wizard, this will be changed to default to
not-provisioned until the user has confirmed all the relevant UI.
Merge commit '0d725f7d5a7efd9dc63f6ddb67a619d659bb4428'
* commit '0d725f7d5a7efd9dc63f6ddb67a619d659bb4428':
Hold a wakelock during backup/restore/clear operations
We need to make sure we stay alive for the duration of a backup or (especially)
restore operation. The existing Handler-based timing system was simply not
properly functional, so it's been retooled to use a repeating alarm delivering a
broastcast PendingIntent to our registered receiver.
We acquire a partial wake lock in the broadcast receiver [i.e. while the Alarm
Manager is holding one for the duration of broadcast delivery] and pass the
wakelock object to the backup thread, which eventually releases it when it's
finsihed operations. A similar pattern is used for the threads handling restore
and clear.
Merge commit 'e15df4017c3625de700e9f9953073f38898bbc89'
* commit 'e15df4017c3625de700e9f9953073f38898bbc89':
If we can't get the restore set's metadata, don't continue
Merge commit '9701b3d594868bd6750d5887af560c6295ea091b'
* commit '9701b3d594868bd6750d5887af560c6295ea091b':
Remove the constraint to assign new uid when code path changes for system packages
Merge commit '4e3e50cfa7cf02270ed0dd454d5c51bf7065bd14'
* commit '4e3e50cfa7cf02270ed0dd454d5c51bf7065bd14':
Clean up the last two literal permission string usages
There are 2 types of vibrations: simple and repeated. Simple vibrations run for
a given length of time while repeated patterns run until canceled or the calling
process dies.
If a vibration is currently running and another request is issued, the newer
request always takes precedence unless the current vibration is a simple one and
the time left is longer than the new request.
If a repeating vibration is running and a new request overrides that vibration,
the current vibration is pushed onto a stack. Once the new vibration completes,
the previous vibration resumes. IBinder tokens are used to identify Vibration
requests which means that multiple calls to Vibrator.vibrate with the same
Vibrator object will override previous vibrations on that object.
