I can't believe I let this slip through. And in the SDK no less. :(
The APIs for setting preferred activities will now throw a security
exception when used. This may break some apps, we'll see how it
goes. If it is too bad we can just make these log and not throw
anything, but I would much prefer they throw an exception.
Change-Id: I3aed434750eef8b202aa9d5bd774a0121be521c6
Extract all UI behavior from dock observer and ACTION_DOCK_EVENT.
Also introduce a desk type to go along with the car type all through
the resource system, since we now need to have corresponding high-level
broadcasts for desk dock mode. As part of that I also reworked some
of the logic for switching modes to all funnel through a single
update() call that looks all of the current state to decide what to
do next, and fixed various locking issues.
In addition I found there were bugs in the configuration change
handling causing us to only switch into the car mode config and
then never get out of it. Unfortunately now that we are actually
changing the configuration for each mode change, the transitions
between them are really crummy as we restart all kinds of
activities. :(
Any package can now participate in backup/restore, without requiring any
manifest-declared permission. *Control* of the backup manager is still
guarded by the BACKUP permission, which is signatureOrSystem.
Change-Id: I116fcfcd4cd255e3c976330da1c4dea7d4faae9d
The device mode is now called ui mode. Furthermore is the order of
precedence for the resources now in such a way that the ui mode needs
to be specified after the orientation and before the density.
The ui mode can be set, like it is done for the locale, as follows:
IActivityManager am = ActivityManagerNative.getDefault();
Configuration config = am.getConfiguration();
config.uiMode = Configuration.UI_MODE_TYPE_CAR | Configuration.UI_MODE_NIGHT_ANY;
am.updateConfiguration(config);
To allow users to disable the car mode and set the night mode the IUiModeManager
interface is used.
The automatic night mode switching will be added in a separate change.
events (and in one case, a DropBox entry).
Add a simple intent that triggers master-clear (and toggle EFS), given the
right permissions.
Bug: 2264596
Bug: 2350452
Bug: 2264596
Still TODO: patch into forthcoming callbacks from
MountService so the USB storage activity always shows the
correct state of the device. (Right now it only refreshes
its display onResume.)
Bug: 2299129
Add new remote interface to do temporary copies. The new
remote stub handling is done on mHandler thread and doesn't need locking
for now.
Add new InstallArgs class and subclasses to isolate cases for installation.
Move resource deletion for failed installs/upgrades to later on in installation
cycle.
Fix code path for forward locked apps when using scanPackageLI
TODO's
Fix installation paths to completely use InstallArgs based design later on.
Get rid of using flags in various install/uninstall code paths.
Ideally InstallArgs should be created using these flags and used in the
rest of the code.
Function renames.
Revisit mount api's.
This adds new DevicAdmin, DevicePolicyManager, and DeviceAdminInfo classes.
See the java docs for each on documentation on them. Basically: a DeviceAdmin
is what you derive from to administer a device; DevicePolicyManager is what you
use to apply and check your policy requirements and perform other administration
tasks.
All of the permissions in data/etc/platform.xml are defined in
core/res/AndroidManifest.xml, except for ACCESS_CACHE_FILESYSTEM. Add
it.
Change-Id: If7906bc0007484cc21196fb1c0593b967fd79920
The ActivityManager.restartPackage() API is now deprecated, and no longer
allows applications to mess up the state of other applications. This was
being abused by task killers, causing users to think their other applications
had bugs.
A new API is introduced for task killers,
ActivityManager.killBackgroundProcesses(), which allows these applications
to kill processes but only the same amount that the out of memory
killer does, thus causing no permanent damage. The old restartPackage()
API is now a wrapper for calling this new API.
There is also a new private forceStopPackage() API that is used for the
system's force stop UI which does what the old restartPackage() API did.
and add a note to the CAMERA permission stating that it enables
the <uses-feature> for camera.
This is an incrimental update for the 2.0.1 docs. More changes
to come for the 2.1 docs to include more features
In order to unbundle System Update, we need some to expose in the SDK
some way to reboot the device into recovery. Add a reboot() method to
PowerManager, protected by the android.permission.REBOOT permission.
as a temporary measure so unbundled Google components (GSF, etc.) can hold
it. (In the longer term, WRITE_GSERVICES won't be a system permission at
all, but it or something like it will be defined directly by GSF.)
You can no longer receive CONFIGURATION_CHANGED in a manifest, which is really really
bad (launching apps every time the screen is rotated!). A new LOCALE_CHANGED broadcast
is sent that you can receive in a manifest.
Change-Id: I80022375f0716db2e672382a29db3cea1af74702
Turning off backup in the Settings UI constitutes an opt-out of the whole
mechanism. For privacy reasons we instruct the backend to wipe all of the data
belonging to this device when the user does this. If the attempt fails it is
rescheduled in the future based on the transport's requestBackupTime()
suggestion. If network connectivity changes prompt the transport to indicate a
backup pass is appropriate "now," any pending init operation is processed before
the backup schedule is resumed.
The broadcasts used internally to the backup manager are now fully protected;
third party apps can neither send nor receive them.
(Also a minor logging change; don't log 'appropriate' EOF encountered during
parsing of a backup data stream.)
Lot of infrastructure for more things to go away when "clear system dialogs"
happens, and now do this when we turn on the lock screen.
Change-Id: I567130296fe47ce82df065ed58ef21b37416ceaf
Applications can now specify two more aspects of the restore process: whether
they need to run with their own custom Application subclass rather than being
launched in the usual restricted mode during restore, and whether it's okay for
the backup manager to kill the app process once restore has completed. The new
manifest attributes for these are, respectively, android:restoreNeedsApplication
and android:killAfterRestore.
If unspecified in the manifest, restoreNeedsApplication is false, and
killAfterRestore is true.
In order to support kill-after-restore cleanly, this change also adds a new
system-process-only interface to the Activity Manager, which will schedule a
"commit suicide" event on the target app's main thread looper.
The framework backup agents have been given the appropriate new backup
attributes as well.
Yet more work on improving the behavior of wallpapers. This fixes a few
problems in their lifecycle (corresponding change in the picker also
required for this), makes their animations better for hardware that supports
alpha fades, adds animations for the wallpapers themselves, eliminates
fixed size wallpapers, and adjusts the API for retrieving a wallpaper
bitmap to take care of scaling the raw wallpaper image to match the current
desired width and height.
Change-Id: If1c0aaceba4ea4e175dcb7a8416ca7ddbb9bfa6f
Merge commit 'c678a93a73c83e841032874bee9c202936da73c0' into eclair
* commit 'c678a93a73c83e841032874bee9c202936da73c0':
Fix issue #2056585: applications can put phone in inconsistent state wrt airplane mode
Packages that do not use android.permission.BACKUP_DATA will neither be backed
up nor restored. That permission is currently signature-only. In the future if
access to the backup/restore infrastructure is made available to arbitrary 3rd
party applications, the permission checks (and indeed, the permission itself)
can simply be removed.
