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.
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>
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.
* 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.
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.
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.
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.
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.
1. the certtool.h is modified for avoiding the side effect,
for saving the configuration with wpa_supplicant.
2. put the loadLibrary back in CertTool.java
3. Fix incorrect JNI declarations.
Without the metadata we can't verify the version number or the signatures of the
apps whose data we'd be trying to restore against the apps present on device.
This is not acceptable; we need to refuse to give data to an unauthenticated
app.
It's now possible to ask that the backup manager wipe the saved data for a given
application from the backing store. LocalTransport implements this now but the
Google backend does not yet. When the data is wiped, the on-device backup state
is also wiped to ensure that the next backup pushes all necessary data.
Bmgr has not yet been modified to actually call into this method, but it will
be soon.
The system now keeps a tag of the last version (just an arbitrary string)
that the setup wizard was run for. If this is different than the current
one in the setup wizard, then setup is launched at boot.
This introduces a new intent action for the part of the setup wizard that
gets run for an ungrade, which the system uses to find its current version
tag for comparing against what was last stored. It is up to the launched
setup activity update the stored setting to reflect its current value,
once it is happy.
This changes the backup service to use the settings provider instead
of system properties, correspondingly making it off by default and
allowing specific devices to define the transport. Also tweaks
the permission checks to use the permission symbol instead of raw
strings.
This requires some corresponding changes in the vendor projects.
We now schedule a periodic check of pending backups; if any apps have requested
a backup since the last check, we perform all of the pending backups. The
periodic backup scheduling matches the enable/disable state of the backup
manager; while backups are disabled entirely there are no periodic wakeups.
The period is set here to one hour. If an external caller (transport, the
'bmgr' command line tool, etc) requests an immediate backup pass, that is
performed and then the periodic backup check is rescheduled using that pass as
the starting point of a new interval.
This is a little hacky -- we just assume that if adb is enabled and power
is connected through usb, then it is active.
The icons and text are temporary until final design is provided.
It turns out this was not a problem in the resource code at all. Rather,
the system process has a cache of pre-loaded attributes it uses to avoid
continually reloading things as it needs them. Well it turns out this
cache wasn't flushed after a package was uninstalled or a configuration
changed, so you could re-install an app where you change its style resources
so its theme now points to one that is inconsistent in the cache.
This is mostly a problem for developers, where they continually install
new versions of an app where resources have changed. This could possibly
show up when updating an app on a normal phone, although the problem would
eventually correct itself since this cache uses weak references.
Anyway, the cache is now reworked to be flushed appropriately.
This change also includes an update to aapt to be able to dump the
contents of bags in resources.
We now store the app version codes and and global OS incremental version name in
the PM backup state and the actual backup record. We then use that information
to trigger a re-backup of the metadata if the OS revision changes in any way, or
to back up single apps' metadata if we notice that they've been upgraded.
We were accidentally submitting a deletion for the global metadata key in the
PM backup handling (it was falling into the usual "here's a package that we said
we'd backed up last time, but now it's no longer on device" code). Don't do
that any more, i.e. actually keep the global metadata key in the backup set.
Oops.
Backup & restore is still enabled by default, but with the expectation that it
will be enabled during the course of the Setup Wizard or some other privileged
entity that has notified the user about the ramifications. While disabled,
data-changed notices will still be collected, but no backup pass will be
scheduled. When the backup manager is later enabled, any pending data-changed
notices will then be processed and the apps invoked for backup.
