This issue was automatically created by Allstar.

Security Policy Violation
Project is out of compliance with Binary Artifacts policy: binaries present in source code

Rule Description
Binary Artifacts are an increased security risk in your repository. Binary artifacts cannot be reviewed, allowing the introduction of possibly obsolete or maliciously subverted executables. For more information see the Security Scorecards Documentation for Binary Artifacts.

Remediation Steps
To remediate, remove the generated executable artifacts from the repository.

Artifacts Found

• encryptionrunner/ukey2.jar

Additional Information
This policy is drawn from Security Scorecards, which is a tool that scores a project's adherence to security best practices. You may wish to run a Scorecards scan directly on this repository for more details.

Allstar has been installed on all Google managed GitHub orgs. Policies are gradually being rolled out and enforced by the GOSST and OSPO teams. Learn more at http://go/allstar

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

https://docs.partner.android.com/gas/integrate/companion_app/cd_phone_sdk

open code 404

Hi,

I'm working on android auto. The app runs on DHU but publishing in Google Play was rejected:

Reason: application asks for an update which prevents testing of functionality in the Android Auto environment.

Don't know what's the reason is. Does anyone know what's to do?

the link for the instructions of your sdk is unfortunately dead.
posted this question also in stackoverflow and got the hint to ask here at your place.

Thanks, Alejandro

The existing source code is built upon version 3.1.2. Upon inspecting the Maven library , I discovered that a more recent version, 3.2.1, is now accessible. When can we anticipate the availability of the updated source code for this new version?

Hello,

I am writing to report a recurring issue observed in the Bluetooth communication handling of our application after updating to Android 14. The application is experiencing unexpected behavior when receiving Bluetooth packets, which was not present in Android 13. Below is the log output that captures the essence of the problem:

W/PacketPayloadStream ( 2804): Received a first message that is not the start of a packet. Ignoring.
I/BluetoothGattManager( 2804): Received data from service 5e2a68a4-27be-43f9-8d1e-4546976fabd7
I/BluetoothMessageStreamV2( 2804): Received packet 9 of 9 for message 269 containing 90 bytes.

The warning W/PacketPayloadStream ( 2804): Received a first message that is not the start of a packet. Ignoring. suggests that there is a discrepancy in how packet starts are being identified in the Bluetooth data stream.

This issue is consistently reproducible on devices that have been updated to Android 14. The same application running on Android 13 does not exhibit this problem, indicating that there has been a change in the Bluetooth stack or relevant system handling that is causing these messages to be misinterpreted or mishandled.

I would greatly appreciate any guidance or acknowledgment of this issue. If there are any workarounds or insights into the nature of these changes in Android 14's Bluetooth handling, it would be beneficial for our development team to know.

Thank you for your attention to this matter.