And related:
- The aapt tool now sets a resource configurations sdk level to match any configs
that have been set (for example if you specify density your sdk level will be
at least 4).
- New option to modify the targetPackage attribute of instrumentation.
- Clean up of aapt options help.
- Fix of UI type values to leave 0 for "unspecified".
- Make the UI mode config APIs public.
Also add ability for admins to hide themselves when not in use,
a facility for admins to not allow other admins to reset
their password, and debug dumping.
Dont invoke getInstallLocation for forward locked apps.
If INSTALL_ON_SDCARD is selected as default, forward locked
apps are not being installed because of conflicting flags.
- ActiveSyncInfo
- ContentResolver.addStatusChangeListener
- SYNC_OBSERVER_TYPE_SETTINGS
- SYNC_OBSERVER_TYPE_PENDING
- SYNC_OBSERVER_TYPE_ACTIVE
- make the ContentService resilient to nulls passed in to the
status change listener registration and unregistration calls
bug http://b/issue?id=2337197
This is the framework part, moving classes around so the framework
no longer needs to link to android-common. Makes some APIs public,
others that didn't need to be public are private in the framework,
some small things are copied.
If a backup-participating app sets android:restoreAnyVersion="true" in its
manifest <application> tag, then its agent will be invoked for restore
even if the available dataset was created by a later version of the app
than is currently installed on the device. This will not typically be
a problem for third party applications, since for them the installation
and initial data restore are tightly coupled, but it can cause serious
problems for applications which are both preinstalled on the system
partition and overridden by later updates. The primary difficulty
that this new attribute addresses is this:
1. User buys a Nexus One, Market self-updates, and the user installs some apps.
At this point the backup data on the server may indicate that the version of
Market which originated its bookkeeping is newer than the stock N1 Market app.
2. User loses their phone, and buys a replacement N1. At setup time, Market
has not yet had a chance to self-update, so when the restore comes in, it's
tagged as being from "the future" and so the restore is refused. No apps get
reinstalled.
Bug: 2442127
Change-Id: I076a9553dc613e5c3189350e778315718ed1ed2b
Add null checks to a few places to avoid crashes when dumping
debug data.
Also add some sanity checks for accessing content providers in
the activity manager.
change hard coded path in installd
fix tests
Work around for renaming containers.
Do forced unmount when destroying containers.
Force a gc in default container service to release handle to parsed package
and thus avoid getting killed by vold
Some cosmetic changes to PackageManager api.
Unit tests for renaming container for MountService
Remove internal size limit on app to be installed.
Turns out the database is used a ton, and not particularly quickly, so
these were spamming the logs at their prior 100ms thresholds. Setting
it to 500ms now. (still sub-sampled, so should be ~5x less spammy...)
The ui modes can be controlled with the UiModeManager class, which
is can be retrieved as a system service via getSytemService(Context.UIMODE_SERVICE).
The class is necessary so that CarHome can be unbundled and other apps can
disable the car mode. Its currently a hidden class, since I'm not sure if this
is the best way to provide this functionality to the user.
I am getting tired of writing package monitor code, realized this is missing in
a number of places, and at this point it has gotten complicated enough that I
don't think anyone actually does it 100% right so:
Introducing PackageMonitor.
Yes there are no Java docs. I am still playing around with just what this
thing is to figure out what makes sense and how people will use it. It is
being used to fix this bug for monitoring voice recognizers (integrating the
code from the settings provider for setting an initial value), to replace
the existing code for monitoring input methods (and fix the bug where we
wouldn't remove an input method from the enabled list when it got
uninstalled), to now monitor live wallpaper package changes (now allowing
us to avoid reverting back to the default live wallpaper when the current
one is updated!), and to monitor device admin changes.
Also includes a fix so you can't uninstall an .apk that is currently enabled
as a device admin.
Also includes a fix where the default time zone was not initialized early
enough which should fix issue #2455507 (Observed Google services frame work crash).
In addition, this finally introduces a mechanism to determine if the
"force stop" button should be enabled, with convenience in PackageMonitor
for system services to handle it. All services have been updated to support
this. There is also new infrastructure for reporting battery usage as an
applicatin error report.
When an application being installed defines a backupAgent in its manifest, we
now automatically perform a restore of the latest-known-good data for that app.
This is defined as "data backed up by this app from this handset, if available;
otherwise data for this app as it existed when the device was initially
provisioned." If neither option exists for the app, no restore action is
taken.
The CL involves major changes in the Backup and Package Managers...
* The Package Manager's act of installing an application has now been split
into two separate phases, with a data-restore phase optionally occurring
between these two PM actions. First, the details of the install are performed
as usual. Instead of immediately notifying install observers and issuing the
install-related broadcasts, the in-process install state is snapshotted and
the backup manager notified that a restore operation should be attempted. It
does this by calling a new API on IBackupManager, passing a token by which it
identifies its in-progress install state.
The backup manager then downloads [if possible] the data for the newly-installed
application and invokes the app's backupAgent to do the restore. After this
step, regardless of failure, it then calls back into the Package Manager to
indicate that the restore phase has been completed, supplying the token that
was passed in the original notification from the Package Manager.
The Package Manager then runs the final post-install actions: notifying install
observers and sending out all the appropriate broadcasts. It's only at this
point that the app becomes visible to the Launcher and the rest of the OS.
... and a few other bits and pieces...
* The ApplicationInfo.backupAgentName field has been exposed to the SDK. This
can be reverted if there's a reason to do so, but it wasn't clear that this
info needs to be hidden from 3rd party apps.
* Debug logging of restore set IDs and operation timeout tokens [used during
any asynchronous Backup Manager operation] are now consistently in hex for
readability.
* We now properly reset our binder identity before calling into the transport
during restore-set operations. This fixes a permissions failure when a
single-app restore was attempted.
* The 'BackupTest' test app is no longer lumped onto the system partition
by default.
Change-Id: If3addefb846791f327e2a221de97c8d5d20ee7b3
- only pass the authtoken through from the authenticator to the client
for getAuthToken() and strip it out from the other calls, like
addAccount(). http://b/2332762
- beef up the documentation to indicate what calls are allowed to be made
from the main thread and which are not allowed. http://b/2384961
- wait a bit before retrying syncs that failed because one was already
in progress. http://b/2414235
This is a bunch of reworking of how configuration changes are handled:
- When orientation is changing (for whatever reason), the window manager no
longer tries to pre-emptively compute a new configuration. Instead, it
just determines change is happening and tells the window manager.
- The activity manager is now responsible for giving the window manager the
final configuration it is using. This is both so it knows whem the
activity manager is done with its configuration updates, and so the window
manager can use the "real" configuration.
- When an orientation or other configuration change is happening, freeze the
screen and keep it frozen until the activity manager has given us the
final configuration.
- The window manager can now send new configurations to its clients during
its layout pass, as part of a resize, if it has determined that it has
changed. This allows for a new View.onConfigurationChanged() API for any
view to easily find out when the configuration has changed.
- ViewRoot now also works with the activity thread to make sure the process's
current resources are updated to the new configuration when it receives one
from a window. This ensures that at the time onConfigurationChanged() and
other view callbacks are happening, the correct configuration is in force.
- There is now a sequence number associated with Configuration, which
ActivityThread uses to avoid using stale configurations. This is needed now
that it can receive configurations asynchronously from both the window
manager and activity manager.
- The hack for keeping the locale has been removed, and underlying problem
fixed by having Configuration initialize its locale to "unknown" instead of
a valid default value.
Changes include
Add new remote call in default container service to determine
install location.
Rename INSTALL_ON_SDCARD
Remove recommentAppInstall method
Add some additional flags used in remote stubs.
Move check for protected apps prior to copy.
Unit tests
DefaultContainerService first parses the file uri(if content uri is specified
it returns a default install internal only value) and returns
a recommended location. Based on which the temporary id is determined
either a file name or a container id and the file is copied there.
This is then later renamed during install.
Todo's light weight parsing of package when determining location since we
just need the install location attribute only when finding out
recomended location. This will also enable to move the check for
updated system apps(cannot be on sdcard) prior to copying.
This will allow Market and others to find out what the "real" name
of a package is, when it is currently running under the old name of
a previously installed version.
Previously, SQLiteDatabase was using Debug.threadCpuTimeNanos(), which
doesn't include I/O time (user-perceived latency), and ContentResolver
was using System.currentTimeMillis(), which didn't account for deep
sleeps.
Now both are consistently using SystemClock.uptimeMillis().
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.
We now have the new package retain the name of the old package. This makes
sure that all existing references to it (shortcuts, widgets, etc) will still
work.
This does mean that your package can run under either the old or new name,
depending on whether the user got it with an update. Buyer beware!
I have tried testing all of the paths of updating, installing another
update in /data, uninstalling the update, updating system with an even
newer update, etc. I think they all work. No promises though.
The new attribute can be set by adding android:safeMode="true"
in AndroidManifest.xml with the SDK.
Tested with pairing locally compiled SDK with Eclipse and verified that the JIT
(the only component currently included in the safe mode) is indeed disabled
with the new attribute.
Bug: 2267583
Change recommendAppInstallLocation api
add code to parse new attribute.
Define flags in PackageInfo
Add new settings attributes for enabling setting and value for install location
Some tests
The policy for install location: if explicitly set in manifest as internal only we try to install the app only on internal storage. if set to preferExternal, we try to install it on sdcard if possible. If not we fall back to internal.
If the user enables setting SET_INSTALL_LOCATION(which will always
be set to false in final release builds) and sets a prefered location, we try
to honour it.
Just like with db_operation, operations over 100ms are always logged,
while operations under that are subsampled.
This will help with performance analysis, getting real-world
performance numbers from dogfooders.
This implements the spec for external storage organization, and
properly reflects how the media scanner organizes the files it finds.
Also includes package manager support for removing app private
files from external storage when the application is uninstalled.
For the new APIs and paths, the main place to look is Environment
and Context.
- Move android.storage.* -> android.os.storage.* and refactor users
- Refactor generic shares back to explicit ums enable/disable/isEnabled
- Remove media insert/removed event callbacks (not ready for Froyo)
- Remove 'label' from volume state change callbacks
- Add public API functions for enabling/disabling USB mass storage (permissions enforced
in MountSevice)
- Remove some stray un-needed import lines
- Move android.os.IMountService / android.os.IMountServiceListener -> android.os.storage
- Improve code comments
Updated:
MountService: Add dup state check and move debugging behind a conditional
UsbStorageActivity: Fix review comments + a TODO
StorageNotification: Add @Override tags
StorageManager: Don't use a static Listener list
MountService: Reduce bloat and fix == where I meant .equals()
PackageManagerTests: Update for new API
Signed-off-by: San Mehat <san@google.com>
- make the sync dump handle the case where there are no accounts
- fix a bug that caused the SyncManager to burn up CPU in the system process
The following was implemented:
scheduler offers:
- settings to disable sync
- retries of certain errors
- backoffs
want a way to control these when scheduling a sync
- "ignore_settings"
- "ignore initial backoff"
- "manual" : ignore settings, ignore initial backoff
- "do not retry"
- need to change the default behavior of not retrying manual syncs to retry regardless
