Move PhoneStateListener for listening to cell location changes from LocationManagerService
to the NetworkLocationProvider.
Move CellState class out of the core framework to the NetworkLocationProvider service.
NetworkLocationManager now notifies the collector of its state, rather than LocationManagerService.
BUG=1729031
Original author: lockwood
Automated import of CL 144600
Move PhoneStateListener for listening to cell location changes from LocationManagerService
to the NetworkLocationProvider.
Move CellState class out of the core framework to the NetworkLocationProvider service.
NetworkLocationManager now notifies the collector of its state, rather than LocationManagerService.
BUG=1729031
Automated import of CL 144599
Remove 1 Hz "heartbeat" polling of location providers from LocationManagerService.
Now location providers report their location to LocationManagerService via
LocationManager.setLocation() rather than waiting to be polled.
This reduces GPS fix latency by up to one second.
Remove LocationProvderImpl.getLocation().
Since we are no longer polling, this method is no longer necessary.
BUG=1729031
Original author: lockwood
Automated import of CL 144453
Remove 1 Hz "heartbeat" polling of location providers from LocationManagerService.
Now location providers report their location to LocationManagerService via
LocationManager.setLocation() rather than waiting to be polled.
This reduces GPS fix latency by up to one second.
Remove LocationProvderImpl.getLocation().
Since we are no longer polling, this method is no longer necessary.
BUG=1729031
Automated import of CL 144452
LocationManagerService now listens for changes to settings,
making LocationManager.updateProviders() unnecessary.
Removed LocationManager.updateProviders()
Added Settings.Secure.setLocationProviderEnabled(), which is a thread-safe way
of enabling or disabling a single location provider.
This is safer than reading, modifying and writing the LOCATION_PROVIDERS_ALLOWED directly.
BUG=1729031
Original author: lockwood
Automated import of CL 144415
2 levels as recorded at plug and unplug events. During charge cycles this would be useful because it would tell us
what the start and end levels were in the last discharge cycle. However during a discharge cycle this information could
be misleading as it would give you the level at the last unplug event (beginning the the discharge cycle) and last plug
event (end of the previous discharge cycle).
Now we are still keeping track of 2 values, but they are "discharge cycle start level" and "discharge cycle current level".
During a discharge cycle this will give you the level the current discharge cycle started at, and the current level. During
a charge cycle the same data will be supplied as before (the start/end of the last discharge cycle).
Original author: emillar
Automated import of CL 144410
Added a screen to the setup wizard, after login, to ask user to
opt-in for location collection.
Added a dialog to Settings when user turns on Network location.
Fixed a security permission issue in LocationManagerService related
to this change.
Original author: yamasani
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 144395
LocationManagerService now listens for changes to settings,
making LocationManager.updateProviders() unnecessary.
Removed LocationManager.updateProviders()
Added Settings.Secure.setLocationProviderEnabled(), which is a thread-safe way
of enabling or disabling a single location provider.
This is safer than reading, modifying and writing the LOCATION_PROVIDERS_ALLOWED directly.
BUG=1729031
Automated import of CL 144372
2 levels as recorded at plug and unplug events. During charge cycles this would be useful because it would tell us
what the start and end levels were in the last discharge cycle. However during a discharge cycle this information could
be misleading as it would give you the level at the last unplug event (beginning the the discharge cycle) and last plug
event (end of the previous discharge cycle).
Now we are still keeping track of 2 values, but they are "discharge cycle start level" and "discharge cycle current level".
During a discharge cycle this will give you the level the current discharge cycle started at, and the current level. During
a charge cycle the same data will be supplied as before (the start/end of the last discharge cycle).
B=144249
Automated import of CL 144333
Added a screen to the setup wizard, after login, to ask user to
opt-in for location collection.
Added a dialog to Settings when user turns on Network location.
Fixed a security permission issue in LocationManagerService related
to this change.
Original author: yamasani
Merged from: //branches/cupcake/...
Automated import of CL 144257
Added a screen to the setup wizard, after login, to ask user to
opt-in for location collection.
Added a dialog to Settings when user turns on Network location.
Fixed a security permission issue in LocationManagerService related
to this change.
BUG=1752566
Automated import of CL 144256
#1748954 (New status bar fades into all white background): FrameLayout wasn't updating its foreground drawable when its padding changed, which would happen as the status bar is shown and hidden. To fix this I also ended up fixing a problem in the view debug stuff where we couldn't get a bitmap for a view that is the full screen size because it is too big... actually I just went ahead and added another function to snapshot the view hierarchy which works a lot better for us anyway.
#1737952 (Home screen icons overlap with the notification bar after exiting any camera app): Originally I punted this because it only happened in rare situations, but now that home is always portrait it happens a lot more so it is more important to fix. This involved a few things to clean up hiding/showing the status bar:
- We now determine when to hide and show it during layout, which allows us to do this at the time it is actually needed rather than during animation after we can actually catch it for the initial display of a window. This required tweaking the layout API so the policy can request a second layout pass if needed.
- When doing layout, we are now much more aggressive about skipping the layout of windows. Basically anything that we know will be hidden in the near future is ignored for layout, so that it doesn't glitch as it is transfered out of the screen. The theory being that it is better to leave it as it was originally placed while we are transitioning it out, than to switch it to something slightly more correct.
Original author: hackbod
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143901
#1748954 (New status bar fades into all white background): FrameLayout wasn't updating its foreground drawable when its padding changed, which would happen as the status bar is shown and hidden. To fix this I also ended up fixing a problem in the view debug stuff where we couldn't get a bitmap for a view that is the full screen size because it is too big... actually I just went ahead and added another function to snapshot the view hierarchy which works a lot better for us anyway.
#1737952 (Home screen icons overlap with the notification bar after exiting any camera app): Originally I punted this because it only happened in rare situations, but now that home is always portrait it happens a lot more so it is more important to fix. This involved a few things to clean up hiding/showing the status bar:
- We now determine when to hide and show it during layout, which allows us to do this at the time it is actually needed rather than during animation after we can actually catch it for the initial display of a window. This required tweaking the layout API so the policy can request a second layout pass if needed.
- When doing layout, we are now much more aggressive about skipping the layout of windows. Basically anything that we know will be hidden in the near future is ignored for layout, so that it doesn't glitch as it is transfered out of the screen. The theory being that it is better to leave it as it was originally placed while we are transitioning it out, than to switch it to something slightly more correct.
Original author: hackbod
Merged from: //branches/cupcake/...
Automated import of CL 143899
#1748954 (New status bar fades into all white background): FrameLayout wasn't updating its foreground drawable when its padding changed, which would happen as the status bar is shown and hidden. To fix this I also ended up fixing a problem in the view debug stuff where we couldn't get a bitmap for a view that is the full screen size because it is too big... actually I just went ahead and added another function to snapshot the view hierarchy which works a lot better for us anyway.
#1737952 (Home screen icons overlap with the notification bar after exiting any camera app): Originally I punted this because it only happened in rare situations, but now that home is always portrait it happens a lot more so it is more important to fix. This involved a few things to clean up hiding/showing the status bar:
- We now determine when to hide and show it during layout, which allows us to do this at the time it is actually needed rather than during animation after we can actually catch it for the initial display of a window. This required tweaking the layout API so the policy can request a second layout pass if needed.
- When doing layout, we are now much more aggressive about skipping the layout of windows. Basically anything that we know will be hidden in the near future is ignored for layout, so that it doesn't glitch as it is transfered out of the screen. The theory being that it is better to leave it as it was originally placed while we are transitioning it out, than to switch it to something slightly more correct.
BUG=1748954,1737952
Automated import of CL 143896
Adds stats for:
- Number of raw user events that have happened in the system.
- Number of times user activity has been reported, dividied by UID and type of activity.
- Duration of screen brightness levels in 4 buckets.
- Per-UID tracking of who has turned on Wifi and how long we can attribute it being on because of them.
Original author: hackbod
Merged from: //branches/cupcake/...
Automated import of CL 143800
Adds stats for:
- Number of raw user events that have happened in the system.
- Number of times user activity has been reported, dividied by UID and type of activity.
- Duration of screen brightness levels in 4 buckets.
- Per-UID tracking of who has turned on Wifi and how long we can attribute it being on because of them.
Original author: hackbod
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143823
Adds stats for:
- Number of raw user events that have happened in the system.
- Number of times user activity has been reported, dividied by UID and type of activity.
- Duration of screen brightness levels in 4 buckets.
- Per-UID tracking of who has turned on Wifi and how long we can attribute it being on because of them.
BUG=1743326
Automated import of CL 143748
take place.
This has the same underlying cause as bug #1739874, so this fixes that
bug as well. The problem was that if the supplicant was in the DORMANT
state at the time a scan-only Wi-Fi lock was released, the command to
stop the Wi-Fi driver would never be issued. This had two main results:
first, the driver would stay awake when the screen was blank and it was
supposed to be sleeping, leading to excessive battery drain, and second,
when the screen was turned back on, there would be no DRIVER-STARTED
event generated (because the driver was already running). The
DRIVER-STARTED event is the trigger for the framework to issue a
RECONNECT command to the supplicant to cause it leave the DORMANT state
and look for available remembered networks.
To assist in tracking down this problem, and any such problems in the
future, I added four counters to keep track of how many times full and
scan-only Wi-Fi locks are acquired and released. The counter values
are output in the dump() method of WifiService. While doing this, I
noticed that because of missing "break" statements, the battery stats
that keep track of how much time Wi-Fi locks are held were including
the time for full locks in the time reported for scan-only locks.
Original author: ers
Merged from: //branches/cupcake/...
Automated import of CL 143266
take place.
This has the same underlying cause as bug #1739874, so this fixes that
bug as well. The problem was that if the supplicant was in the DORMANT
state at the time a scan-only Wi-Fi lock was released, the command to
stop the Wi-Fi driver would never be issued. This had two main results:
first, the driver would stay awake when the screen was blank and it was
supposed to be sleeping, leading to excessive battery drain, and second,
when the screen was turned back on, there would be no DRIVER-STARTED
event generated (because the driver was already running). The
DRIVER-STARTED event is the trigger for the framework to issue a
RECONNECT command to the supplicant to cause it leave the DORMANT state
and look for available remembered networks.
To assist in tracking down this problem, and any such problems in the
future, I added four counters to keep track of how many times full and
scan-only Wi-Fi locks are acquired and released. The counter values
are output in the dump() method of WifiService. While doing this, I
noticed that because of missing "break" statements, the battery stats
that keep track of how much time Wi-Fi locks are held were including
the time for full locks in the time reported for scan-only locks.
Original author: ers
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143395
Also do most of the work for issue #1732012 (Only show screen rotation animation when triggered by sensor). This just needs to be hooked up to the surface flinger API when that appears.
Original author: hackbod
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143318
Also do most of the work for issue #1732012 (Only show screen rotation animation when triggered by sensor). This just needs to be hooked up to the surface flinger API when that appears.
Original author: hackbod
Merged from: //branches/cupcake/...
Automated import of CL 143169
take place.
This has the same underlying cause as bug #1739874, so this fixes that
bug as well. The problem was that if the supplicant was in the DORMANT
state at the time a scan-only Wi-Fi lock was released, the command to
stop the Wi-Fi driver would never be issued. This had two main results:
first, the driver would stay awake when the screen was blank and it was
supposed to be sleeping, leading to excessive battery drain, and second,
when the screen was turned back on, there would be no DRIVER-STARTED
event generated (because the driver was already running). The
DRIVER-STARTED event is the trigger for the framework to issue a
RECONNECT command to the supplicant to cause it leave the DORMANT state
and look for available remembered networks.
To assist in tracking down this problem, and any such problems in the
future, I added four counters to keep track of how many times full and
scan-only Wi-Fi locks are acquired and released. The counter values
are output in the dump() method of WifiService. While doing this, I
noticed that because of missing "break" statements, the battery stats
that keep track of how much time Wi-Fi locks are held were including
the time for full locks in the time reported for scan-only locks.
BUG=1731826,1739874
Automated import of CL 143124
