| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* All profiles use the BluetoothProfileConnector but not Pbap.
I reproduced the changes that were made in aosp/932813 for all other
profiles. This allow pbap to no longer call resolveSystemService.
* `Intent.resolveSystemService` is an hidden API and can no longer be
called from Bluetooth as we aim to become mainline. It's code is simple
enough to be copied.
Tag: #refactor
Bug: 200200870
Test: atest BluetoothInstrumentationTests
Change-Id: I838b910c633b3ca943fec01f3ccca466ff65f892
|
|
Attributable is called by bluetooth and it's hidden.
By copying into bluetooth we are now allowed to call it
Bug: 210467788
Test: build
Tag: #refactor
Change-Id: I73ea07c9439988ab5477c82799f718c6d81513be
|
|
This API is called by a mainline module (Bluetooth), and needs
to be change to an available API.
Bug: 200200870
Tag: #refactor
Test: Build + start bt + switch user and restart bt
Change-Id: I37bb0d16e61d666d0aa51d5efe48fa9b39f9c1c3
|
|
Since developers can use a BluetoothDevice object can make remote
calls, it needs to have an accurate AttributionSource. Previous CLs
had updated many places where these BluetoothDevice instances were
passed across Binder interfaces, but this change updates several
remaining locations which had been missed.
Introduces new "Attributable" marker interface to offer consistent
tooling when applying AttributionSource updates.
Bug: 187097694
Test: atest BluetoothInstrumentationTests
Change-Id: Icad3b9726591f0fbad58a493cefa5a0af7648280
|
|
As part of the new "Nearby devices" permission work, the
registerStateChangeCallback() API has been relaxed to no longer
require permissions. However, we've discovered that some apps were
depending on that SecurityException being thrown, so this change
restores throwing behavior for those legacy apps.
Bug: 186176507
Test: atest BluetoothInstrumentationTests
Change-Id: Ife536dee246b300ffb3dd78aef0b059a230f3835
|
|
Wires up AttributionSource across the remaining long-tail of
Bluetooth AIDL interfaces, ensuring that developers can accurately
make calls chained back to a specific Context.
Moves "for data delivery" permission checks to happen in a single
location on each interface to ensure they're performed consistently
with the new AttributionSource arguments. Note that "for data
delivery" isn't the best name; it's designed to represent that the
requested action was performed and should result in the relevant
appop being noted for the caller.
This change has the positive side effect of ensuring that all
interfaces are consistently enforcing the BLUETOOTH_CONNECT
permission, even in the case where BLUETOOTH_PRIVILEGED is also
required; this is what ensures that revoking the "Nearby devices"
permission takes effect for all callers.
Additionally, standardizing on enforcing permissions closer to the
AIDL entry point reduces the need for @RequiresPermission annotations
to be carried around inside the Bluetooth stack.
Bug: 183626112
Test: atest BluetoothInstrumentationTests
Change-Id: I8023dda654e325b8bfa2f0cdb994ad63a2b429d4
|
|
To prepare for future work which will plumb AttributionSource values
through all remaining AIDLs, we need profiles to interact directly
with the specific BluetoothAdapter they were created from. This is
how we'll ensure that the relevant AttributionSource can be chained
down from the original Context they're obtained from.
This change also marks getDefaultAdapter() as deprecated to clearly
communicate that BluetoothManager.getAdapter() is the best-practice
path to obtaining a correctly scoped BluetoothAdapter instance.
Bug: 183626112
Test: atest BluetoothInstrumentationTests
Change-Id: I1e15170d7679019bbb6e396279d6e633e3dad4d6
|
|
Recent work has been using Error Prone rules and annotations to
reflect the current state of permission enforcement across the
Bluetooth stack, and we're now in a position were we can add new
permission enforcement that had been missing.
We've currently standardized on saying that APIs that return device
or Bluetooth state information (without sharing details about any
particular remote Bluetooth device) do not need to be permission
protected.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: I53ac7a4fe1dea57316048c3cac4fa237b6ba3d38
|
|
This change adds a "BluetoothPermissionChecker" that ensures that
all Bluetooth permission annotations are consistent. In addition, it
verifies that all Bluetooth public APIs have been audited to be
permission protected where relevant.
We've currently standardized on saying that APIs that return device
or Bluetooth state information (without sharing details about any
particular remote Bluetooth device) do not need to be permission
protected.
This change is only annotations and has no behavior changes.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: Ie80b15b058359bf1e9a6ee881b89cb3e5b584ca1
|
|
Recent work has introduced a new "Nearby devices" runtime permission
which protects all existing Bluetooth APIs; we've done this by
defining a <split-permission> to convert the old BLUETOOTH and
BLUETOOTH_ADMIN permissions into one of three new permissions:
* BLUETOOTH_ADVERTISE: Required to be able to advertise to nearby
Bluetooth devices.
* BLUETOOTH_CONNECT: Allows applications to connect to paired
bluetooth devices.
* BLUETOOTH_SCAN: Required to be able to discover and pair
nearby Bluetooth devices.
At its core, this change begins updating the Bluetooth APIs to have
correct @RequiresPermission indicating which permission is actually
enforced internally. To ensure alignment across Binder, the newly
added "RequiresPermissionChecker" Error Prone checker was used to
discover any inconsistencies, ensuring correctness from server-side
enforcement up through to the public APIs.
In addition, since developers will continue building apps for both
modern and legacy platforms, this change introduces new auto-doc
annotations which will emit helpful consistent documentation
describing the behavior of older devices that are still using the
old permission model.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: I02aa127e8e07f239561f4f2a3bbdfc6fccb82f7f
|
|
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
This is a resubmit of ag/12929664 with some APIs excluded that caused
test failures; see bugs 171886397, 171888296, 171864568.
APIs excluded:
Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord;
Landroid/os/Process;->myPpid()I
Landroid/os/SharedMemory;->getFd()I
Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I
Bug: 170729553
Test: Treehugger
Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
|
|
This reverts commit bc9a809f18a3b0ec23cbc39802fb4928c2074ea3.
Reason for revert: Droidcop-triggered revert due to breakage https://android-build.googleplex.com/builds/quarterdeck?testMethod=testAppZygotePreload&testClass=android.app.cts.ServiceTest&atpConfigName=suite%2Ftest-mapping-presubmit-retry_cloud-tf&testModule=CtsAppTestCases&fkbb=6936597&lkbb=6936969&lkgb=6936551&testResults=true&branch=git_master&target=cf_x86_phone-userdebug>, bug b/171886397
Bug: 171886397
Change-Id: Ibe0f0430a3451477c1ee8ef56a596e91ea1e7672
|
|
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
|
|
SystemApis and for hidden connect/disconnect APIs.
Hide some APIs that were previously marked as @UnsupportedAppUsage and re-add annotation as changing the permissions for these SystemApis would break the unsupported app contract that was previously there. Therefore, we're choosing to hide them until we have a good story on how to deal with them next release.
Bug: 148689314
Test: Manual
Change-Id: I33ee2c7ccd3827db3d23d6447cf82d9ffc36836a
|
|
true on successfully setting the connection policy instead of on
disconnection. It also now indicates that if
BluetoothProfile#CONNECTION_POLICY_FORBIDDEN is passed in, the profile
will be disconnected.
Bug: 148966894
Test: Manual
Change-Id: I881c240fcbce0c8148625c35e6e88ab02ea7122f
|
|
instance of the class, add intdef to return value of
BluetoothPbap#getConnectionState, and move all SystemApis to require
the BLUETOOTH_PRIVILEGED permission
Bug: 148966894
Test: Manual
Change-Id: I4a798b0a16ab839f2047fc58f21c420cc99b6db6
|
|
|
|
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I6ab53570aca580fbee1fcc927871caa09780f58f
Merged-In: I6ab53570aca580fbee1fcc927871caa09780f58f
|
|
the method in Pbap.
Bug: 147444905
Test: Manual
Change-Id: I308b29d8ce96f9e410a66d59379a731ae12e0478
|
|
Bug: 145943634
Test: Manual
Change-Id: I72fc624d5c6578ca0374a1e943810d97b6361250
|
|
Bug: 145943634
Test: Manual
Change-Id: I23b2b20f97968696f9f00fee55094db6e551835f
|
|
* In current design, Bluetooth AdapterState stops all BR/EDR
profiles' service and triggers onServiceDisconnected callback to
all binder clients before BluetoothManagerService invokes
onBluetoothStateChange(false), which means unbind service
would never be called in framework.
* Do unbind service when onServiceDisconnected is invoked.
* Move profile binder logic to BluetoothProfileConnector except:
- BluetoothHeadset: its binder logic is in BluetoothManagerService
- BluetoothPbap: it has an individual ServiceListener
Bug: 129037442
Bug: 129437895
Test: Bluetooth ON/OFF stress test.
adb shell dumpsys activity services | egrep "com.android.bluetooth"
to check whether AppBindRecord for com.android.bluetooth grows
Merged-In: Id0d85866d386962b94d2d966f0a864b1da165d13
Change-Id: Id0d85866d386962b94d2d966f0a864b1da165d13
|
|
When the corresponding profile service is not available on device,
bluetoothA2dp, bluetoothHidHost and bluetoothPbap will report
IllegalArgumentException when bluetooth is disabled. This change avoid
that exception.
Bug: 127359897
Test: local test and observe there is no IllegalArgumentException when
bluetooth is disabled
Change-Id: I457e5225b8710dd5d02c405ef558892e99d1736f
(cherry picked from commit ee8371007b82ff8c6d26e8ac90c6e3d3cf6bf2a8)
|
|
am: b40b37910d
Change-Id: Ic3de9e4c6d17687d4a1f64c02026e5c0711e8fd1
|
|
For packages:
android.bluetooth.le
android.bluetooth
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: Ifcf24c0617acd7facc0e03f30a95c3a6b09b205c
Merged-In: I88a1311e27c5f9a5f9d1035db76034f86f650efc
|
|
The majority of Manager-style classes already use Context.getUserId()
when making calls into the OS, so clean up the remaining callers to
unify behind this strategy.
This gives @SystemApi developers a nice clean interface to interact
across user boundaries, instead of manually adding "AsUser" or
"ForUser" method variants, which would quickly become unsustainable.
Test: builds, boots
Bug: 72863821
Exempt-From-Owner-Approval: trivial changes
Change-Id: Ib772ec4438e57a2ad4950821b9432f9842998451
|
|
* BluetoothPbap will implement BluetoothProfile to be consistent with
other profiles
* Changed the method names to match the BluetoothProfile method
signatures
* Removed doesClassMatchSink() as it is never used
* Disable default DEBUG logs
Test: test with carkits
Bug: 69417672
Change-Id: I0766188f77468808d7505780c781f5fd8608af60
|
|
* Use ACTION_CONNECTION_STATE_CHANGED to broadcast connection state
change to comply with BluetoothProfile interface requirement
* Use BluetoothProfile.STATE_* variables to represent connection
states for PBAP profile
Bug: 63873163
Test: Connect to car kits
Change-Id: I7dfcfc1b3a3e4868ea5e313f62ad5e504d58b9c2
|
|
* Binder object may become null between null check and actual invocation
if using a instance private variable assignable by service connection
callbacks
* The solution to this problem without locking is to assign existing
binder variable to a local final variable before the null check
* Any further invocation to a disconnected binder object will result in
RemoteException that is caught by the try-catch block
* Read and write to volatile variable is always atomic and hence thread-safe
* Removed unnecessary synchronization in BluetoothAdapter constructor
* Private mConnection objects should be final
* Simplfied several return statements where booleans can be returned
directly
* Removed unnecessary catches for NPE since there won't be any
Bug: 64724692
Test: make, pair and use devices, no functional change
Change-Id: Ifc9d6337c0d451a01484b61243230725d5314f8e
|
|
* Manual style corrections with IDE assistance
* Variable name refactors are done through IDE
* Corrected general style errors such as:
- "final private var" -> "private final var"
- "&&", "+", "||" should not be at the end of line
- Non-static private variable should be like "mVar"
- Private static variable should be like "sVar"
- Code file should always end with newline
- Inherited methods should be annotated with @Override
and no @hide tags
- Public methods should always have a JavaDoc entry
- "int[] array" is preferred over "int array[]"
- private methods should be accessed without "this."
when there is no name collisions.
- "boolean ? true : false" -> boolean
- "boolean ? false : true" -> !boolean
- "boolean == true" OR "boolean != false" -> boolean
- "boolean != true" OR "boolean == false" -> !boolean
Bug: 63596319
Test: make checkbuild, no functional changes
Change-Id: Iabdc2be912a32dd63a53213d175cf1bfef268ccd
|
|
* Automatic style corrections through IDE
Bug: 63596319
Test: make checkbuild, no manual changes, no functional changes
Change-Id: I2397d55abc34c9b7a9b748bec6137778df3421a7
|
|
W/ContextImpl( 1772): Calling a method in the system process without a qualified user: android.app.ContextImpl.bindService:1559 android.content.ContextWrapper.bindService:513 android.bluetooth.BluetoothInputDevice.doBind:262 android.bluetooth.BluetoothInputDevice.<init>:255 android.bluetooth.BluetoothAdapter.getProfileProxy:1365
W/ContextImpl( 1772): Calling a method in the system process without a qualified user: android.app.ContextImpl.bindService:1559 android.content.ContextWrapper.bindService:513 android.bluetooth.BluetoothPan.doBind:148 android.bluetooth.BluetoothPan.<init>:140 android.bluetooth.BluetoothAdapter.getProfileProxy:1368
W/ContextImpl( 1772): Calling a method in the system process without a qualified user: android.app.ContextImpl.bindService:1559 android.content.ContextWrapper.bindService:513 android.bluetooth.BluetoothMap.doBind:108 android.bluetooth.BluetoothMap.<init>:101 android.bluetooth.BluetoothAdapter.getProfileProxy:1374
W/ContextImpl( 1772): Calling a method in the system process without a qualified user: android.app.ContextImpl.bindService:1559 android.content.ContextWrapper.bindService:513 android.bluetooth.BluetoothPbap.doBind:163 android.bluetooth.BluetoothPbap.<init>:156 com.android.settings.bluetooth.PbapServerProfile.<init>:68
Change-Id: I0a1e24ee71aef7d796fcee5692b9d19462a93637
|
|
Change-Id: Ia1f99bd2c1105b0b0f70aa614f1f4a67b2840906
|
|
Fix BluetoothPan closing sequence for unregsiter state change callback
bug 11160007
Change-Id: I405ec91a938289fe9541de2ebd9abc1fb938f44a
|
|
The bindService() and startService() calls have always had
undefined behavior when used with an implicit Intent and there
are multiple matching services. Because of this, it is not
safe for applications to use such Intents when interacting with
services, yet the platform would merrily go about doing... something.
In KLP I want to cause this case to be invalid, resulting in
an exception thrown back to the app. Unfortunately there are
lots of (scary) things relying on this behavior, so we can't
immediately turn it into an exception, even one qualified by the
caller's target SDK version.
In this change, we start loggin a WTF when such a call happens,
and clean up some stuff in Bluetooth that was doing this behavior.
Change-Id: I62e25d07890588d2362104e20b054aebb6c0e007
|
|
Change Ieb51bafb46c895a21d2e83696f5a901ba752b2c5 left out some
files, this fixes them.
Change-Id: Ia949a8581668836ea0251602e048f09c852f5169
|
|
bug 7174712
Change-Id: I8d3fdc8edbe42068b5a550660d7b24854c3c4af4
|
|
Remove ACTION_CONNECT_OTHER_PROFILES as it is no longer used
Allow only PRIORITY_ON and PRIORTY_OFF as priority params for SetPriority()
API in BluetoothA2DP and BluetoothHeadset
BluetoothPBAP: Pass on proxy object as part of Service Connected callback
Change-Id: Ida00fc2b7d1dcb91b01f7ddd2cea482367a3b334
|
|
Change-Id: Ia5fc3db1bb51824e7523885553be926bcc42d736
|
|
Bug: 5572649
Change-Id: I62f9e0620832b69995d5c6e1c24634c9a3895a4b
|
|
* Fix some typos in Javadoc and log messages.
* Remove redundant initializer in BluetoothAdapter.readOutOfBandData()
* Use canonical "UTF-8" charset name instead of "UTF8" in
BluetoothDevice.convertPinToBytes()
Change-Id: I58cd5dc48a7ad0053d204c5f590b4b3d438d8672
|
|
This is a large batch, and covers:
-- Bluetooth Device Discovery --
BluetoothAdapter.ACTION_DISCOVERY_STARTED
BluetoothAdapter.ACTION_DISCOVERY_FINISHED
BluetoothAdapter.startDiscovery()
BluetoothAdapter.cancelDiscovery()
BluetoothAdapter.isDiscovering()
-- Bluetooth bonding (pairing) --
BluetoothAdapter.getBondedDevices()
BluetoothDevice.ACTION_BOND_STATE_CHANGED
BluetoothDevice.EXTRA_BOND_STATE
BluetoothDevice.EXTRA_PREVIOUS_BOND_STATE
BluetoothDevice.BOND_NONE
BluetoothDevice.BOND_BONDING
BluetoothDevice.BOND_BONDED
BluetoothDevice.getBondState()
BluetoothDevice.createBond()
BluetoothDevice.cancelBondProcess()
BluetoothDevice.removeBond()
-- BluetoothClass --
BluetoothDevice.ACTION_CLASS_CHANGED
BluetoothDevice.EXTRA_CLASS
BluetoothDevice.getBluetoothClass()
BluetoothClass.Service.*
BluetoothClass.Device.Major.*
BluetoothClass.Device.*
BluetoothClass.getDeviceClass()
BluetoothClass.getMajorDeviceClass()
BluetoothClass.hasService()
-- Misc BluetoothDevice --
BluetoothDevice.ACTION_ACL_CONNECTED
BluetoothDevice.ACTION_ACL_DISCONNECTED_REQUESTED
BluetoothDevice.ACTION_ACL_DISCONNECTED
BluetoothDevice.ACTION_DISCOVERED
BluetoothDevice.ACTION_NAME_CHANGED
BluetoothDevice.EXTRA_DEVICE
BluetoothDevice.EXTRA_NAME
BluetoothDevice.EXTRA_RSSI
-- Misc BluetoothAdapter --
BluetoothAdapter.ACTION_LOCAL_NAME_CHANGED
BluetoothAdapter.EXTRA_LOCAL_NAME
BluetoothAdapter.checkBluetoothAddress()
I deprecated BluetoothIntent and moved each intent into the class it relates
to.
Change-Id: I877b1280428ab46278b2bc25668bb44cda22dc36
|
|
Split BluetoothDevice into BluetoothDevice and BluetoothAdapter.
BluetoothAdapter: Represents the local BT adapter. Operations on the local
adapter (start a scan, etc).
BluetoothDevice: Represents a remote BT device. Operations on remote devices
(pair, connect, etc).
IBluetoothDevice.aidl -> Bluetooth.aidl
BluetoothDeviceService.java -> BluetoothDeviceService.java
TODO:
Javadoc
|
|
|
|
- Update according to comments
- Add aidl support in frameworks for Settings to retrieve current
PBAP transaction status.
- Add status bar support for PBAP
|
