- 'setPermanentlyLocked(false)' no longer automatically resets the pattern
- new string for "waiting to verify account" progress dialog
- new string for account unlock screen title when you aren't past the too many
attempts, but just hit the 'forgot pattern' button
The problem was instigated by another fix I made to keep
windows around while their tokens are animating or preparing to
animate. This then hit an issue where if the window's process
died while its token was getting ready to animate, we would
immediately hide the token, and when we then went to start
the token animation we wouldn't do anything, leaving the old
dummy animation in place and not allowing it to run.
Now we clear the animation before hiding the token, to ensure
the dummy animation is gone at this point.
Change-Id: If83fadcce6815bc545c80fbdb82fe6972bbdf5ef
Fixes a problem where mms apn was on when we lost the network (airplane mode) but mms was
off when airplane mode was turned off so it kept thinking we didn't have access and
future mms always failed.
bug: 2075145
During orientation changes or homing, the volume is reverted. Also,
during pause/resume, the original and modified values are remembered and
restored if the dialog was up.
One of the problems I have been noticing is background services
sitting around running and using resources. Some times this is
due to the app developer doing this when they shouldn't, but there
are also a number of issues with the current Service interaction
model that make it very difficult (or impossible) to avoid
getting services stuck in the started state. This is a
change/enhancement to the Service API to try to address this.
The main change is that Service.onStart() has been deprecated,
replaced with a new Service.onStartCommand() that allows the
service to better control how the system should manage it. The
key part here is a new result code returned by the function, telling
the system what it should do with the service afterwards:
- START_STICKY is basically the same as the previous behavior,
where we usually leave the service running. The only difference
is that it if it gets restarted because its process is killed,
onStartCommand() will be called on the new service with a null
Intent instead of not being called at all.
- START_NOT_STICKY says that, upon returning to the system, if
its process is killed with no remaining start commands to
deliver, then the service will be stopped instead of restarted.
This makes a lot more sense for services that are intended to
only run while executing commands sent to them.
- START_REDELIVER_INTENT is like START_NOT_STICKY, except if
the service's process is killed before it calls stopSelf()
for a given intent, that intent will be re-delivered to it
until it completes (unless after 4 or more tries it still
can't complete, at which point we give up).
Change-Id: I978f5ca420d70023d1b5e7f97de639d09381f8ad
Merge commit 'b385508d89747e4c383979f1cc6fa2814b1cedbd' into eclair
* commit 'b385508d89747e4c383979f1cc6fa2814b1cedbd':
Add more code samples to the online docs.
Add build rules to include the development samples in the droiddoc build process.
Add all the sample screenshots to a new samples/images/ directory
Revise the samples homepage to include links to new samples
Remove the code that hides the title bar when the page finishes loading.
When the user double taps, if it did not result in changing the viewing
mode (i.e. on a mobile site), send a message to the client so we can
toggle the title bar's visibility. Required for a change to
packages/apps/Browser
Change-Id: I0040fd183ce5673a4069e943f38eb31599c0ca7d
The onSizeChange code is called when the device is rotated and
when the title bar is hidden. In the latter case, it is in response
to the zooming transition from overview mode to reading mode, and
the zoom center should not be recomputed.
http://b/issue?id=2060720
