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.
We are replaceing the package name in the activity name with a * iff the activity is in the
same package, otherwise the activity name is pritned out in full.
This small change will remove a lot of bytes (in the order of kilobytes for a real log) from the logged data on the network and downstream processing,
since the package name is repeated in almost all cases.
An exampe of the new format is here:
DUMP OF SERVICE usagestats:
D:4,20090813
P:com.android.launcher,4,155456
A:*.Launcher,4,0,0,0,0,0,0,0,0,0,2
P:com.android.browser,1,6724
A:*.BrowserActivity,1,0,0,0,0,0,0,0,0,0,0
A:*.CombinedBookmarkHistoryActivity,1,0,0,0,0,0,0,0,0,0,1
P:com.google.android.apps.maps,1,2219
A:com.google.android.maps.MapsActivity,1,0,0,0,0,0,0,0,0,0,0
P:com.android.contacts,1,0
A:*.DialtactsActivity,1,0,0,0,0,0,0,0,0,0,1
This was a problem with not dealing well with how the driver was
reporting data in the old touch protocol.
Also fixed issue with not correctly rotating non-primary touches.
This also refactors ConnectivityService a bit towards supporting multiple simultaneous connections by making each a seem like a seperate Network with it's own stateTracker, etc.
Also adds tracking of process death to clean orphaned startUsingNetworkFeature features.
Merge commit 'fe6e733a01b1ab8a6c7b651c65bf7abeb97f9525'
* commit 'fe6e733a01b1ab8a6c7b651c65bf7abeb97f9525':
Fix issue #2049588: App widget can crash causing system to be unable to boot
Wait until system is booted before attempting to display the shutdown dialog.
Use ShutdownActivity rather than attempting to run ShutdownThread in the battery service.
Fix logic error (check !isPowered() instead of isPowered())
Signed-off-by: Mike Lockwood <lockwood@android.com>
Specifically, don't wait for the RestoreObserver to be informed that the restore
has completed unless performRestore() ran. We were winding up in a case where
bmgr was hanging forever waiting on a nonexistent restore process instead of
calling endRestoreSession().
Also improve the documentation, explicitly calling out the need to call
endRestoreSession() even if previous operations on the session were
unsuccessful.
This currently only works for a wallpaper that is larger than the
screen. Set the scroll position with the new wallpaper API. Right
now only does jump scrolls.
This adds a new theme for having a wallpaper, and fixes up the window manager
to do the right thing when transitioning between a windows with and without
wallpapers (between two windows with wallpapers is not yet addressed).
The wallpaper API now has callbacks to tell you when to start/stop animating.
Also fiddle the image wallpaper to be a little more interesting.
This is all of the basic pieces:
- The WallpaperService now creates a surface with the window manager for its
contents.
- There is a simple service that displays a bitmap.
- The wallpaper manager takes care of starting and stopping the service.
- The window manager knows about wallpaper windows and how to layer them with
the windows that want to be shown on top of wallpaper.
Lots and lots of issues remain, but at this point you can actually write a
wallpaper service, select it in the UI, and see it behind an activity.
This is because doing it through the Activity Manager also makes sure that the
app has been shut down first, which is quite a desirable invariant for restore
handling.
Merge commit '40c10bf4dfbaf2a48b3fe6d2fcc58843cefc01bc'
* commit '40c10bf4dfbaf2a48b3fe6d2fcc58843cefc01bc':
More work on issue #2030135: Device sluggish
This is mostly refactoring, adding a new WallpaperManager class that takes care
of the old wallpaper APIs on Context, so we don't need to pollute Context with
various new wallpaper APIs as they are needed. Also adds the first little
definition of a wallpaper service, which is not yet used or useful.
This adds some new debugging code to make it easier to see why a process is at
a certain oom_adj level -- for example telling you that a certain other process
has a binding to a certain one of its services. This has helped a lot in
identifying cases where processes are holding references to other processes that
they don't need and thus not allowing the system to get memory it needs.
Also fix a few problems with leaking entries on the service restarting and
service stopping lists.
Merge commit '8b2cdcd184acfebfb245b15a71f5f1c32e53b050'
* commit '8b2cdcd184acfebfb245b15a71f5f1c32e53b050':
fix issue with gids not being added for packages with shared user id
Squashed commit of the following:
commit 2bc4c29dab22d8a541dfca0a20320b307ba64cfb
Author: Suchi Amalapurapu <asuchitra@google.com>
Date: Tue Aug 4 16:24:55 2009 -0700
fix issue with gids not being added for packages with shared user id
Merge commit '89888b2d9dc2d1994a8236ffbce5aaefd6782bf3'
* commit '89888b2d9dc2d1994a8236ffbce5aaefd6782bf3':
Remove debug code which reads the max_events_per_sec property on every touch event
The major things going on here:
- The MotionEvent API is now extended to included "pointer ID" information, for
applications to keep track of individual fingers as they move up and down.
PointerLocation has been updated to take advantage of this.
- The input system now has logic to generate MotionEvents with the new ID
information, synthesizing an identifier as new points are down and trying to
keep pointer ids consistent across events by looking at the distance between
the last and next set of pointers.
- We now support the new multitouch driver protocol, and will use that instead
of the old one if it is available. We do NOT use any finger id information
coming from the driver, but always synthesize pointer ids in user space.
(This is simply because we don't yet have a driver reporting this information
from which to base an implementation on.)
- Increase maximum number of fingers to 10. This code has only been used
with a driver that reports up to 2, so no idea how more will actually work.
- Oh and the input system can now detect and report physical DPAD devices.
