When switching default networks we should erase any excess dns server entries. The old code
used the wrong index and didn't erase all of them properly.
Found in conjunction with
bug: 2077628
Update the RSSI display policy in CDMA.
1. Use single RSSI icon instead of two icons
2. If 3G(EV) and 1x network are available than 3G should be displayed, Displayed RSSI should be from the EV side.
3. If a voice call is made then RSSI should switch to 1x.
We were running out of local refs when there are lots of devices.
Instead of deleting every single local ref, create a local stack frame.
This operation is inexpensive so doesn't add a high overload and keeps
the code clean instead of deleting every single local ref.
- '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
Phase 2
Make VCard Importer use Data structures in ContactsContract instead of
using old Conatacts structure.
Phase 3
Developed VCardComposer, which was originally in Contacts package, but
now in base/core/java. Also made it use queryEntries() as per jsharkey's
suggestion.
Phase 4
Added VCardUtils and moved some common methods to it, some of which should be
in public API, but hidden for now.
Phase 5
Made VCardComposer emits (almost) valid vCard 3.0 data.
Confirmed with vCard data emitted by Mac.
Related issue:
1784580, 1728351, 1967349
Note:
Probable next step:
- Add "fast parse" mode in VCradBuilder, in which, VCardBuilder skip parsing the value of
each property. It will make the parsing faster.
-- Note that parsing the parameters of each entry cannot be skipped, since it may contains
the information about Encoding of the property. In other words, if the line is
in Quoted-Printable format, the next line may be the part of the property, not a
separated property, which should be parsed accordingly.
- Needs test
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
