GPS Provider Service changes
GPS engine needs to receive network state changes from Android fw.
Added db query for the current APN, also added a new parameter
between JNI / HAL to the new method in AGpsRilInterface struct
for gps engine to receive APN from GPSLocationService
Conflicts:
services/java/com/android/server/location/GpsLocationProvider.java
Change-Id: I33c45027f1571493d3525324f62d199517c4960c
Signed-off-by: Mike Lockwood <lockwood@android.com>
GPS engine needs to receive network state changes from Android fw.
Added db query for the current APN, also added a new parameter
between JNI / HAL to the new method in AGpsRilInterface struct
for gps engine to receive APN from GPSLocationService
Change-Id: I62e35c948d2ac1961771d1a10581a3b8e695c05a
Signed-off-by: Mike Lockwood <lockwood@android.com>
Make sure that files that don't exist aren't returning bogus 'out of
space' error codes.
Add some Javadoc so I can remember what each thing does in an IDE.
Add copyright header to NativeLibraryHelper
Bug: 3375299
Change-Id: Iac46019160921daca65b21d38897e5165063316e
Now callbacks can communicate to the same daemon without causing a
deadlock. This also improves the latency of calls because they no
longer need to wait for the callbacks for the pending events.
Change-Id: I153fcf16bd64de79ee1c1a57d3cfdb12b354cf47
Create API to expose quota status derived from underlying network
policy. This is designed to support applications making informed
decisions when performing network requests.
Fix bug with random stats generation, and write policy when changing
restrict background data flag. Deprecate EXTRA_NETWORK_INFO, since
it varies based on UID.
Bug: 4517283, 5088603
Change-Id: Ic6893a8967f69937e466be226ba7bb86ef5a5d2d
When moving from SD card to internal, the PackageManager should check if
the native library directory parent's canonical path matches the
canonical data directory.
However, it was checking the canonical native library directory's
parent matches the data directory which makes tests concerning moving
from SD card to internal storage fail.
Change-Id: I16420efbb6f52fd6877a8f62ad060f8a1b8b0033
This potentially has no impact on mobile due to DNS settings being the same. Seperate this change out of the p2p change
Change-Id: I70fff9b1e13015956793b19732785037adb0af24
Nice to not load 4MB bitmaps in the system process.
Also, hey, with how we are now scrolling the surface instead of
the bitmap, there is no reason to keep that 4MB bitmap loaded in
to memory. So don't.
Unfortunately it looks like for some reason the VM is still
holding on to the bitmap. I'll need to figure out why. Later.
Change-Id: Ib3503756144502fc5c8d5e294248c2417c4fe8c8
Provide API to increment "operation counts" for a UID and tag, used
to eventually derive bytes/operation stats. Internally is stored at
network layer, but should belong at data layer. Switch profiling
to use data layer stats, which are emulated by summarizing network
layer details.
Read packet counts from new /proc/ columns and collect them into
NetworkStatsHistory. Prevent double-counting by ignoring values from
first snapshot. Watch for duplicate /proc/ entries. Update tests
to verify packet and operation counters.
Bug: 5052136, 5097392
Change-Id: I1832f65a2b8a9188f8088f253474a667c21a2f09
- Improve how we handle processes that have shown UI, to take care
of more cases where we want to push them into the background LRU
list.
- New trim memory level for when an application that has done UI
is no longer visible to the user.
- Add APIs to get new trim memory callback.
- Add a host of new bind flags to tweak how the system will adjust
the OOM level of the target process.
Change-Id: I23ba354112f411a9f8773a67426b4dff85fa2439
Specifically, we now also require the current password to confirm any
restore operation.
Bug 4901637
Change-Id: I39ecce7837f70cd05778cb7e0e6390ad8f6fe3f3
If the user has supplied a backup password in Settings, that password
is validated during the full backup process and is used as an encryption
key for encoding the backed-up data itself. This is the fundamental
mechanism whereby users can secure their data even against malicious
parties getting physical unlocked access to their device.
Technically the user-supplied password is not used as the encryption
key for the backed-up data itself. What is actually done is that a
random key is generated to use as the raw encryption key. THAT key,
in turn, is encrypted with the user-supplied password (after random
salting and key expansion with PBKDF2). The encrypted master key
and a checksum are stored in the backup header. At restore time,
the user supplies their password, which allows the system to decrypt
the master key, which in turn allows the decryption of the backup
data itself.
The checksum is part of the archive in order to permit validation
of the user-supplied password. The checksum is the result of running
the user-supplied password through PBKDF2 with a randomly selected
salt. At restore time, the proposed password is run through PBKDF2
with the salt described by the archive header. If the result does
not match the archive's stated checksum, then the user has supplied
the wrong decryption password.
Also, suppress backup consideration for a few packages whose
data is either nonexistent or inapplicable across devices or
factory reset operations.
Bug 4901637
Change-Id: Id0cc9d0fdfc046602b129f273d48e23b7a14df36
