Implemented reading and writing state to retain information
across boots, API to retrieve state from it, improved location
manager interaction to monitor both coarse and fine access
and only note operations when location data is being delivered
back to app (not when it is just registering to get the data at
some time in the future).
Also implement tracking of read/write ops on contacts and the
call log. This involved tweaking the content provider protocol
to pass over the name of the calling package, and some
infrastructure in the ContentProvider transport to note incoming
calls with the app ops service. The contacts provider and call
log provider turn this on for themselves.
This also implements some of the mechanics of being able to ignore
incoming provider calls... all that is left are some new APIs for
the real content provider implementation to be involved with
providing the correct behavior for query() (return an empty
cursor with the right columns) and insert() (need to figure out
what URI to return).
Change-Id: I36ebbcd63dee58264a480f3d3786891ca7cbdb4c
Use this to track the package name of applications
accessing GPS.
And now the app ops service can enforce that callers
must provide valid package names.
Change-Id: I842a0abe236ea85f77926d708547f0f95c24bd49
Set dns servers for secondary nets and attach the
processes (pids) that are using the secondary nets
to the secondary nets associated dns cache.
Change-Id: Id865c2c3fdc0ec1c3e30c134e9ea4109f4f2fbeb
bug:5465296
The DimLayer behind popups was not changing when the popup layer
changed. It will now.
Fixes bug 7974415.
Change-Id: Ia486efa83d623716a09d73a22493a4222823c573
On some devices, we need to apply heuristics to determine whether
the device is docked on a wireless charger because the charging
circuits do not provide sufficient information to know whether
the device is on the charger unless it is actually receiving
power.
The previous heuristics only considered the battery level to
suppress spurious dock signals.
The new heuristics also take into account whether the device
appears to have moved from its previous position on the dock.
Bug: 7744185
Change-Id: I5ba885dac25b37840b6db46b8a0f30968a06776c
TIME_TICK was not occurred at the end of DST for one hour
Step to reproduce:
1. Settings -> Date & time
2. uncheck Automatic date & time and Automatic time zone
3. select Time zone -> select Brussels
4. set date -> Oct. 28. 2012
5. set time -> 1:59 AM
Bug: 7922117
Change-Id: I2e78bd97b508d6a38471425cfbaca45fb4b89c1e
Initial implementation, tracking use of the vibrator, GPS,
and location reports.
Also includes an update to battery stats to also keep track of
vibrator usage (since I had to be in the vibrator code anyway
to instrument it).
The service itself is only half-done. Currently no API to
retrieve the data (which once there will allow us to show you
which apps are currently causing the GPS to run and who has
recently accessed your location), it doesn't persist its data
like it should, and no way to tell it to reject app requests
for various operations.
But hey, it's a start!
Change-Id: I05b8d76cc4a4f7f37bc758c1701f51f9e0550e15
For finishDrawingWindow queue the performLayoutAndPlaceSurfaces call
and return immediately.
For setTransparentRegionHint call the WindowStateAnimator method
immediately, removing the previous queueing of it.
Fixes bug 7174665.
Change-Id: Ia52f9a6685842220e4ffca6e214ee366470ff666
Replace two classes that did similar things in a complicated manner
with one class that does it more simply.
Bug 7064755 fixed.
Change-Id: I8c415671f60d1d2ece9da5916421f4d24aed2d65
Make app transition states easier to understand.
Remove unnecessary dependence on ActivityOptions.
Change-Id: If3942133e919a4121340f8ef5ca1c50df22f370d
systemReady() was returning before the LocationManagerService was
actually ready. Applications making LocationManager transactions
during their startup could possibly hit a race condition with the
yet-uninitialised LocationManagerService.
To guarantee that LocationManagerService is actually ready before
returning from systemReady(), we simply do the startup work on the
thread that called systemReady(), rather than spin up a secondary
thread to do the work asynchronously.
LocationWorkerHandler still needs a thread to do its work on, so
rather than have it run on the secondary thread that was
previously used for systemReady()'s work, we create a HandlerThread
for it.
Additionally, LocationManagerService.init() really needed to grab
lock for some of the things it was doing. I moved all of the code
that could benefit from mutex protection to a single section of
systemReady() and wrapped it up with a lock while I was at it.
Bug: 7723944
Change-Id: I51d480e2781622c3a14769c3a2019a2407dcfd8a
