This will allow for unique identification of a call as id only provides
uniqueness per session.
Bug: 26016489
Change-Id: I643d24bf5ff5680c26e530075649ef2a4f378295
We introduced some new flag at the lowest significant bit of the
battery level int but failed to account for it when unpacking.
Bug:25596467
Change-Id: I4320e6fcc208ec6de249b14fe3e399ab2f32d839
(cherry picked from commit 6902052c77)
It is possible that older platforms may have not cleared the lock pattern,
but instead only checked this flag to determine the lock pattern enabled
state. In such cases, upgrading to a platform with that only checks the
lock pattern can lead to the lock screen being re-enabled by accident.
These new methods allow this condition to be identified and resolved.
Bug: 26029690
Change-Id: I8f7ebc0e1915049afe49c219c87010aa38a16244
Basically anything Parcelable needs to go since it might be
quite large. Note that this includes additional extras such as
those contributed by WearableExtender.
Cherry-picked from 5012853de2
Bug: 26038546
Change-Id: I00eadd2b23dfc4fccf42332df658373bb05b8a45
It was assumed that when a UID had either rx or tx bytes/packets that it would
have the other as well.
Bug:25706750
Change-Id: Iefac59a6bd02876aed9a0bac218d187b81807a95
In an attempt to better be able to debug Bluetooth-related parts of
the system, add info-level logging including calling process and
thread whenever the aforementioned functions are called.
Bug: 25996120
Change-Id: I5a72b2ab929f805ec1c43cc54879ed079a8dfe34
This is special solution only for emerald branch.
Changes including new const char* value/interface for sensor physical data. Sensor service and manager does not take care of content, structure or other
details of string. Sensor HAL is taking care of parsing data from string and setting values to Sensor HW.
Change-Id: Id19226d7d3ac0628488a0f005f2b1c44bafcf9b6
Signed-off-by: Ben Fennema <fennema@google.com>
We introduced some new flag at the lowest significant bit of the
battery level int but failed to account for it when unpacking.
Bug:25596467
Change-Id: I4320e6fcc208ec6de249b14fe3e399ab2f32d839
This functionality is required by devices which have multiple profiles
using the SCO channel. For example, a device that is both a HFP AG and HF.
In this case, we must explicitly notify the profiles when they can acquire
the channel as they are not aware of each other. A similar change was
previously added to the Bluetooth Headset Client profile.
Bug: 25485578
Change-Id: Ia60cfdd33c2c3c3f185464b24056f8ccb976056d
- Clarify hardware.camera feature being only for the back camera
- Clarify what setting a CaptureRequest field to null does
- Use preCorrectionActiveArray instead of activeArray in list of
possible raw output sizes
- Clarify length of GPS processing field for camera1 API
Bug: 24540625
Bug: 23908116
Bug: 23051627
Bug: 17345901
Change-Id: Iaf11fdf626268cf30f66b3628153ec3ac770c4f4
I think what probably happened is that since we only report an app
going in to the "interaction" state as an interaction event to usage
stats, apps that sit around in that state forever will only see one
interaction at the start and never again. So usage stats could start
thinking they are idle.
Fix this by having the activity manager report an interaction event
for such long running applications at least once a day.
Also, because it is correct and for paranoia by protected us another
way, system uids should never go in to standby.
Change-Id: I8a3805bfca86cbe78560488a649ecd07427da99a
During system boot, we prune app-ops belonging to apps that have
been uninstalled. However, apps installed on adopted storage devices
haven't been scanned at this point, so they appear to be uninstalled.
To avoid pruning app-ops for these apps, we need a getPackageUid()
variant that also considers "uninstalled" apps for which we still
have PackageSetting values.
Bug: 25206071
Change-Id: I1820f674d45c5ddc1c5f10ed7d859e7025005e28
This is being added to help identify system apps so that
the UI can filter on that type.
BUG: 24955055
Change-Id: Ie4be3717ce997f60eeb48a389c0f54ce5803141a
