Don't hold a lock when the activity thread is telling the activity manager
to release a provider.
This requires that the activity manager now keep a reference count on the
providers, because without the lock it is possible for activity thread to
call in to request the provider again before it has finished telling
about the release.
Change-Id: I5f912903891f4edae85e28819d4e6f14b8f2e688
Tell the broadcast receiver whether it is getting an initial sticky value,
so it will be quiet about attempts to do ordered broadcast stuff.
Note that the original bug being reported was not actually a crash, just
an error log. So all we are doing here is making the log quieter.
Change-Id: Iaf1b718d82093ec1197142410a64feff47eb3859
There was a bug with the starting window where it could be added to
the app window list twice, so the buddy list would end up with one
left over after all was done. This would result in visibility
changes not being delivered to it correctly, delaying the dispatch
of onStop.
Change-Id: If1993eaf9cfbba1f523ce5aaa478be0239d0c7db
We now just don't send out dock broadcasts/launches when the
device is not provisioned. Good enough for our purposes.
Change-Id: Iee6384121675e0e9854745ec1168245e8a23a241
Windows with a negative Y position can end up in createSurfaceLocked()
with mFrame containing a negative height, causing SurfaceFlinger to go
crazy when asked to create the surface. This change simply guards
against such a situation by instead asking for a 1x1 surface and relying
or later layout operations to resize the window to the appropriate size.
Change-Id: I66f2058f4cd1cf069b12d3d23e6fd340dc76b74e
(when booted while docked)
This isn't really a fix, but we now have the activity report the configuration
it actually launched in, so the activity manager will later adjust it if
needed. Should help us recover from hitting the race in this particular case.
Change-Id: I3bb83a48c2d692b4cb1822d8ae7d924cfa9187b2
The core logging in BackupManagerService and in the Google backup transport are
still enabled at this point.
Change-Id: I10abfa565bbd1097dd3631051b6aca163e4af33a
Stop using SIM card icons for USB notifications
Fixes b/1700510
Change-Id: Ic7e251a7ecad3ed46044181eae41481791df85bd
Signed-off-by: Mike Lockwood <lockwood@android.com>
If not these system services will end up with inconsistent settings files
when the device runs out of storage.
Delete mangled settings file in PackageManager if the current write fails
so that we don't end up overwriting the backed up version with the
mangled version
Include null check when retrieving fwd locked resource for an existing package
I think when we were scanning the updated app in the system image,
from an older version on the data partition, we were not setting
the existing package to have the system flag, so not auto-granting
any new permissions.
This also includes some other cleanup in the package manager to
remove old files in various places, and tighten up logging.
Also similar logging cleanup elsewhere.
Change-Id: I6d113c7cf7e736ab9be512d6d7c94c806a24199a
* changes:
Only re-initialize backup state if @pm@ metadata is missing, to defensively work around a still-mysterious bug where the list of saved packages ends up being empty even though we still have state pending. If we do re-initialize, then wipe all state to make sure the right thing happens.
to defensively work around a still-mysterious bug where the
list of saved packages ends up being empty even though we still
have state pending. If we do re-initialize, then wipe all state
to make sure the right thing happens.
Don't keep open journal files -- close them after every update.
A bit less efficient, but possibly more reliable (again, this is
defensive programming here). Also change "rwd" to "rws" mode
for fully synchronous operation.
* changes:
- make SyncManager get the accounts list during the constructor, which will allow syncs to be scheduled during bootup. The providers need this so that they can potentially schedule syncs while they are starting up. - make the SyncManager message handler wait until boot has completed to start dispatching messages
which will allow syncs to be scheduled during bootup. The
providers need this so that they can potentially schedule
syncs while they are starting up.
- make the SyncManager message handler wait until boot
has completed to start dispatching messages
We already had a delay if we were associated, but we have some race conditions
we think will be masked if we delay the driver stop for the other cases
too. Don't wait as long (2 min instead of 15).
bug: 2147260
on success, record "backup_initialize" event; on failure,
record "backup_transport_failure" event (and add tags to
"backup_transport_failure" events that aren't associated
with a particular package -- namely "(initialize)" and
"(finish)").
Track requests independently with seperate timers. Clean up on expiration
by just stopping that particular request, not immediately restoring the default.
bug: 2127590
Now that we can have a non-app-window cross-wallpaper animation,
we need to make sure to not access a null app token.
Change-Id: Ia00debd4b2b431d15bd074927a9035e1bc0a6445
The APIs for checking whether keys are held down now also look
at virtual keys.
However it turns out there is less than a second between the time we
start the input thread and check for safe mode, so there is not enough
time to actually open all of the devices and get the data from them
about the finger being down to determine if a virtual key is down.
So now you can also hold DPAD center, trackball center, or s to
enter safe mode. Also give some vibrator feedback.
Change-Id: I55edce63bc0c375813bd3751766b8070beeb0153
If a backup pass had been skipped (either because the transport was unavailable
or -- in a common case! -- because there was simply no work pending when the
periodic backup check fired), we were forgetting to reset the "backup currently
in progress" flag. Once we'd done that, the device would *NEVER* perform a
backup until it was rebooted, since it would forever think that there was one
currently in operation that must not be interfered with.
Change-Id: I0d6d7375dc6de99b599222a449934e70fe13ebb9
This was introduced when I did the fading of the lock screen,
which relies on setting the policy visibility of the windows behind
it to be hidden. As a result, when the orientation changed or
the activity was restarted, they wouldn't be resized or reported
as drawn, and the activity manager would wait until its timeout
before unfreezing the screen.
We now have a new method on WindowState to find out if a window
has drawn itself, which is used in the appropriate places.
Change-Id: If05f8b1947d3029917f62ad0f89b43544bd0a4dc
Also trigger low battery when battery reaches the specified level
rather than when it drops below the level.
Fixes bug b/1788656
Change-Id: I81f5cbb9892fc6574320d92e153211f83c69f415
Signed-off-by: Mike Lockwood <lockwood@android.com>
The TelephonyRegistry service crashed badly in the generic build, because
there is no system property to tell if the phone is GSM or CDMA. Adding a
simple null check solves the issue and allows the system to boot properly.
- The lock screen now fades in and out.
- Fixed a bug where we would accidentally freeze the screen when switching
to an activity with a different orientation than the current (but
the screen itself is in the current orientation). This would mess up
the animations on the car dock.
- New API to force a particular animation for an activity transition
(untested).
- New wallpaper animations.
- Resources now uses the next API version when in a development build,
to help applications being developed against such builds.
Change-Id: I2d9998f8400967ff09a04d693dc4ce55f0dbef5b
* changes:
Fix bug 2129190 The context used by the status bar (i.e., the system context) was not properly initialized to have the right ApplicationInfo inside its PackageInfo. This eventually caused it to believe that it was running at 160dpi.
The context used by the status bar (i.e., the system context) was
not properly initialized to have the right ApplicationInfo inside
its PackageInfo. This eventually caused it to believe that it
was running at 160dpi.
Kudos to Dianne for figuring this out.
