CN112889096B

CN112889096B - Method for dynamically adjusting AVRCP version and terminal equipment

Info

Publication number: CN112889096B
Application number: CN201880098310.8A
Authority: CN
Inventors: 国珊珊; 萧维廷; 唐能福; 宋业全
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2018-12-07
Filing date: 2018-12-07
Publication date: 2022-05-24
Anticipated expiration: 2038-12-07
Also published as: CN112889096A; WO2020113591A1

Abstract

A method and a device for dynamically adjusting AVRCP version relate to the field of chip technology and chip security, and can solve the problem that a TG supporting high-version AVRCP can possibly cause that a CT can not display song information when playing music files in the TG. The method comprises the following steps: the terminal equipment responds to a first SDP request message sent by opposite terminal equipment, and sends a first SDP response message to the opposite terminal equipment, wherein the first SDP response message carries a version number of a first AVRCP version (601); the terminal device responds to at least two browsing request messages sent by the opposite terminal device, and the browsing request messages are used for the opposite terminal device to request to display the media information of the media player (602); and the terminal equipment responds to a second SDP request message sent by the opposite terminal equipment, the second SDP request message is sent when the terminal equipment is disconnected with the opposite terminal equipment and then is connected again, a second SDP response message is sent to the opposite terminal equipment, and the carried version number of the second AVRCP version is lower than that of the first AVRCP version (603). The method and the device are used for how the CT acquires the media information when the TG is connected with the CT through Bluetooth.

Description

Method for dynamically adjusting AVRCP version and terminal equipment

Technical Field

The present application relates to the field of chip technologies and chip security, and in particular, to a method and a terminal device for dynamically adjusting an Audio/Video Remote Control protocol (AVRCP) version.

Background

AVRCP defines how to control features of streaming media including pause, stop, start playback, volume control, and other types of remote control operations. AVRCP defines two device roles, namely, a control device (CT) and a target device (TG). CT is typically a remote control device and TG is a device whose characteristics can be changed. The CT may initiate the transfer process by sending a command frame to the TG, which may receive the command frame and respond with the command frame. The CT may be a Personal Computer (PC), a Personal Digital Assistant (PDA), a telephone, a car system, an earphone, a playing/recording device, and the like, and the TG may be a playing/recording device, a television, an earphone, and the like. For example, CT is a vehicle-mounted system, TG is a mobile phone, when the mobile phone and the vehicle-mounted system are connected by bluetooth technology, the vehicle-mounted system can control the mobile phone to play music, display information such as the state, song title, and singer of the mobile phone when playing music, and can also browse music files and display play lists on the mobile phone.

The AVRCP has a plurality of service versions, the compatibility of different versions is different, if the TG supports the AVRCP of high version, the CT side can not display the song information of the music file if the CT is to play the music file in the TG.

Disclosure of Invention

The embodiment of the application provides a method for dynamically adjusting the version of AVRCP, which can solve the problem that a TG supporting high-version AVRCP can possibly cause that a CT cannot display song information when the CT plays music files in the TG.

In a first aspect, a method for dynamically adjusting AVRCP version is provided, which is applied to a terminal device; the terminal equipment comprises a media player, and the method comprises the following steps: the terminal equipment responds to a first Service Discovery Protocol (SDP) request message sent by opposite terminal equipment, and sends a first SDP response message to the opposite terminal equipment, wherein the first SDP response message carries the version number of a first AVRCP version; the terminal equipment responds to at least two browsing request messages sent by opposite terminal equipment, and the browsing request messages are used for the opposite terminal equipment to request to display the media information of the media player; and the terminal equipment responds to a second SDP request message sent by the opposite terminal equipment, wherein the second SDP request message is sent when the terminal equipment is disconnected from the opposite terminal equipment and then is connected again, a second SDP response message is sent to the opposite terminal equipment, the second SDP response message carries the version number of a second AVRCP version, and the version number of the second AVRCP version is lower than that of the first AVRCP version. The first AVRCP version can represent that the terminal device supports a media player list which can be inquired by the opposite terminal device, and the second AVRCP version can represent that the terminal device does not support the media player list which can be inquired by the opposite terminal device. When the terminal device replies that the AVRCP version number of the opposite terminal device is different, the subsequent link behaviors of the terminal device and the opposite terminal device are also different. Therefore, under the condition that the terminal device supports the media player list of the opposite-end device capable of inquiring the terminal device, if the terminal device receives at least two browsing request messages sent by the opposite-end device, the terminal device can know that the media player requested by the opposite-end device does not support the opposite-end device to access the media information, when the terminal device is connected next time, the terminal device can reduce the first AVRCP version of the terminal device to the second AVRCP version, the opposite-end device cannot send the browsing request messages to the terminal device so as to avoid the condition that the terminal device supports the media player list of the opposite-end device capable of inquiring the terminal device, but the media player requested by the opposite-end device does not support the opposite-end device to access the media information, and the problem that the opposite-end device cannot display the media information due to the fact that the opposite-end device cannot access the media information of the media player is avoided. The terminal device may be, for example, a mobile phone, the opposite terminal device is a vehicle-mounted device, the media player is a music player, and the media information is song information of a music folder of the music player.

In one possible design, the version number of the first version of AVRCP is AVRCP1.4 and the version number of the second version of AVRCP is AVRCP 1.3. That is, when the AVRCP version of the terminal device is AVRCP1.4, the peer device may query the media player list of the terminal device, and when the AVRCP version of the terminal device is AVRCP1.3, the peer device does not subsequently query the media player list of the terminal device, and does not request the media player of the terminal device to browse media information, thereby avoiding a problem that the peer device cannot display media information because the peer device supports the media player list that the peer device may query the terminal device, but the media player of the terminal device does not support access to the media information.

In one possible design, when the terminal device receives a browse request message, the method further includes: and the terminal equipment sends a browse response message to the opposite terminal equipment, wherein the browse response message indicates that the media player does not support the opposite terminal equipment to request to display the media information of the media player. The media player may be, for example, internet music, QQ music, and dog music, among others. The media information may be song information of internet music, for example. Media player does not support requesting, by a peer device, that media information of the media player be displayed may be understood that the media player does not support AVRCP browsing (browsing). Because the AVRCP browsing is not supported, the opposite terminal equipment repeatedly sends browsing request messages to the terminal equipment, and the terminal equipment recognizes that the repeatedly sent behavior indicates that the media player requested by the opposite terminal equipment does not support AVRCP browsing.

In one possible design, if the terminal device receives at least two browsing request messages, the method further includes: the terminal equipment records the equipment information of the opposite terminal equipment in a preset equipment information set; before the terminal device sends the second SDP response message to the peer device, the method further includes: the terminal equipment inquires whether the equipment information of the opposite terminal equipment is in a preset equipment information set or not; and if the equipment information of the opposite terminal equipment is in the preset equipment information set, the terminal equipment determines to send a second SDP response message to the opposite terminal equipment. If the device information of the peer device is in the preset device information set, it indicates that a behavior that the peer device cannot access the media information of the media player of the terminal device occurs in the last connection process between the terminal device and the peer device, which is equivalent to recording the historical behavior, so that when the terminal device is disconnected from the peer device and then connected again, if the peer device requests to know the AVRCP version of the terminal device, the terminal device downgrades and replies to the peer device, so that the link behavior between the terminal device and the peer device changes, and the peer device is prevented from sending a browse request message again, which indicates that the media information cannot be accessed.

In one possible design, the method further includes: and if the equipment information of the opposite terminal equipment is not in the preset equipment information set, the terminal equipment sends a first SDP response message to the terminal equipment. Here, if the device information of the peer device is not in the preset device information set, which indicates that the peer device cannot access the media information of the media player of the terminal device before requesting access, the terminal device may normally reply to the version number of the AVRCP of the peer device without version down reply.

In one possible design, the device information of the peer device includes bluetooth information of the peer device, or the device information of the peer device includes bluetooth information and a device type of the peer device; the Bluetooth information is the first three digits of the Bluetooth address of the opposite terminal equipment, or the Bluetooth information is the Bluetooth name of the opposite terminal equipment, or the Bluetooth information is the first three digits of the Bluetooth address of the opposite terminal equipment and the Bluetooth name; the preset device information set comprises the Bluetooth information of at least one device or the Bluetooth information and the device type of at least one device, or the preset device information set is empty. The Bluetooth address of the equipment generally has six bits, the Bluetooth address of the equipment is unique for each equipment, and if the whole six bits of the Bluetooth address of the equipment are recorded, only the equipment can be recorded, so the first three bits of the Bluetooth address can be recorded, the manufacturer of the equipment can be recorded, other equipment of the manufacturer can be recorded, and the condition that media information cannot be displayed on other equipment of the manufacturer is avoided.

In a possible device, if the terminal device receives at least two browsing request messages, the method further includes: the terminal device sets the content of the AVRCP version field corresponding to the opposite terminal device in the Bluetooth pairing file as the version number of the second AVRCP version, the Bluetooth pairing file comprises device information of the opposite terminal device performing Bluetooth pairing with the terminal device, and the device information comprises the AVRCP version field corresponding to the opposite terminal device. In this way, when the terminal device is disconnected from the peer device and then reconnected, the content of the AVRCP version field of the peer device in the bluetooth pairing file can be queried, so that the AVRCP version of the terminal device is replied to the peer device as the version number of the second ACRVP version.

In one possible design, the second SDP response message further includes characteristics supported by the second AVRCP version; the method further comprises the following steps: and the terminal equipment updates the characteristic of the first AVRCP version in the terminal equipment to the characteristic of the second AVRCP version. That is to say, when the terminal device replies to the AVRCP version number of the peer device, the version-down reply is performed, and at the same time, the parameter value of the AVRCP version characteristic in the terminal device needs to be modified into the parameter value of the reduced version, so that the terminal device and the peer device continue to communicate according to the modified parameter value.

In one possible design, the media information includes song information including a song name, a song quantity, song lyrics, and a song playing time period.

In a second aspect, a terminal device is provided, the terminal device comprising a memory, a processor, a transceiver, and a display, the memory storing instructions that, when executed by the processor, cause the terminal device to: responding to a first SDP request message sent by opposite terminal equipment, and sending a first SDP response message to the opposite terminal equipment, wherein the first SDP response message carries a version number of a first AVRCP version; responding at least two browsing request messages sent by opposite terminal equipment, wherein the browsing request messages are used for requesting the opposite terminal equipment to display the media information of the media player, and sending a browsing response message corresponding to each browsing request message to the opposite terminal equipment, and the browsing response messages indicate that the media player does not support the opposite terminal equipment to request to display the media information of the media player; recording the equipment information of the opposite terminal equipment in a preset equipment information set; responding to a second SDP request message sent by the opposite terminal equipment, wherein the second SDP request message is sent when the terminal equipment is disconnected with the opposite terminal equipment and then is connected again, and inquiring whether the equipment information of the opposite terminal equipment is in a preset equipment information set or not; if the equipment information of the opposite terminal equipment is in the preset equipment information set, sending a second SDP response message to the opposite terminal equipment; the second SDP response message carries the version number of the second AVRCP version, and the version number of the second AVRCP version is lower than that of the first AVRCP version.

In one possible design, the version number of the first version of AVRCP is AVRCP1.4 and the version number of the second version of AVRCP is AVRCP 1.3.

In one possible design, the operations further include: and if the equipment information of the opposite terminal equipment is not in the preset equipment information set, sending a first SDP response message to the terminal equipment.

In one possible design, the device information of the peer device includes bluetooth information of the peer device, or the device information of the peer device includes bluetooth information and a device type of the peer device; the Bluetooth information is the first three digits of the Bluetooth address of the opposite terminal equipment, or the Bluetooth information is the Bluetooth name of the opposite terminal equipment, or the Bluetooth information is the first three digits of the Bluetooth address of the opposite terminal equipment and the Bluetooth name; the preset device information set comprises the Bluetooth information of at least one device or the Bluetooth information and the device type of at least one device, or the preset device information set is empty.

In one possible design, the second SDP response message further includes characteristics supported by the second AVRCP version; the operations further comprise: and updating the characteristic of the first AVRCP version in the terminal equipment to the characteristic of the second AVRCP version.

In a third aspect, a chip is provided, the chip comprising a memory and a processor, the memory storing instructions that, when executed by the processor, cause the chip to perform the method according to the first aspect.

In a fourth aspect, there is provided a terminal device comprising a memory storing computer instructions that, when executed, cause the terminal device to perform the method according to the first aspect.

In a fifth aspect, there is provided a computer storage medium storing computer instructions which, when executed by a computer, cause the computer to perform the method of the first aspect.

Therefore, according to the ACRCP query method provided by the application, when the opposite terminal device cannot access the media information of the media player of the terminal device and cannot display the media information, the terminal device carries out version reduction processing on the AVRCP version, when the terminal device is disconnected with the opposite terminal device and then is connected again, communication is carried out according to the reduced version, and the problem that the opposite terminal device cannot access the media information of the media player of the terminal device and cannot display the media information is avoided.

Drawings

Fig. 1 is a schematic diagram of a network architecture according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of a terminal device according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a Bluetooth protocol architecture followed by TG and CT;

fig. 4 is a schematic diagram of signal interaction between TG and CT querying service versions and characteristics between TG and CT through ACRCP;

FIG. 4A is a schematic diagram of a screen display of a mobile phone and a vehicle-mounted device;

FIG. 4B is a schematic diagram of a screen display of the mobile phone and the in-vehicle device;

fig. 5 is a schematic diagram of signal interaction between TG and CT querying service versions and characteristics between TG and CT through ACRCP;

fig. 6 is a signal interaction diagram of a method for dynamically adjusting AVRCP version according to an embodiment of the present application;

fig. 7 is a signal interaction diagram of a method for dynamically adjusting AVRCP version according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a chip according to an embodiment of the present disclosure;

fig. 9 is a schematic structural diagram of a terminal device according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a terminal device according to an embodiment of the present application.

Detailed Description

The embodiment of the application provides a method and a device for dynamically adjusting an AVRCP version, which can be applied to a process that after a terminal device is connected with an opposite terminal device through Bluetooth, the opposite terminal device plays a media file in the terminal device, for example, after the terminal device is successfully connected with the opposite terminal device through Bluetooth, the opposite terminal device can play and display a music file in the terminal device.

The network architecture of the application can comprise terminal equipment and opposite terminal equipment, wherein the terminal equipment can be equipment which has a Bluetooth function, is provided with a media player and supports AVRCP (Audio video control protocol), such as a mobile phone and a tablet personal computer, and the opposite terminal equipment can be equipment which supports the Bluetooth function, is provided with the media player and supports AVRCP, such as vehicle-mounted equipment, Bluetooth earphones, a PC (personal computer) and the like. As shown in fig. 1, the terminal device 11 may be a mobile phone, and the peer device 12 is a vehicle-mounted device. For example, when the media player is a music player, after the terminal device and the peer device are successfully connected through bluetooth, the peer device can simultaneously play music files in the terminal device while the terminal device displays the music playing progress, and display the state, singer and singer information, etc. of music playing in the terminal device, and the user can also operate the peer device to control the music pause, stop, start playing, volume control and other types of control operations. Here, the terminal device corresponds to TG, and the peer device corresponds to CT.

In one example, the terminal device may be implemented by a structure as shown in fig. 2. Taking a terminal device as a mobile phone as an example, fig. 2 shows a general hardware architecture of the mobile phone for explanation. The handset shown in fig. 2 may include: radio Frequency (RF) circuitry 210, memory 220, other input devices 230, display screen 240, sensors 250, audio circuitry 260, I/O subsystem 270, processor 280, and power supply 290. Those skilled in the art will appreciate that the configuration of the handset shown in fig. 2 is not intended to be limiting and may include more or fewer components than those shown, or some components may be combined, some components may be separated, or a different arrangement of components may be used. Those skilled in the art will appreciate that the display screen 240 belongs to a User Interface (UI), and the display screen 240 may include a display panel 241 and a touch panel 242. And the handset may include more or fewer components than shown. Although not shown, the mobile phone may further include a camera, a bluetooth module, and other functional modules or devices, which are not described herein again.

Further, processor 280 is coupled to RF circuitry 210, memory 220, audio circuitry 260, I/O subsystem 270, and power supply 290, respectively. The I/O subsystem 270 is coupled to the other input devices 230, the display screen 240, and the sensor 250, respectively. The RF circuit 210 may be used for receiving and transmitting signals during a message transmission or a call, and in particular, receives downlink information of a base station and then processes the received downlink information to the processor 280. Memory 220 may be used to store software programs and modules. The processor 280 executes various functional applications and data processing of the cellular phone by executing software programs and modules stored in the memory 220. Other input devices 230 may be used to receive entered numeric or character information and generate key signal inputs relating to user settings and function controls of the handset. The display screen 240 may be used to display information input by or provided to the user and various menus of the handset, and may also accept user input. The sensor 250 may be a light sensor, motion sensor, or other sensor. Audio circuitry 260 may provide an audio interface between the user and the handset. The I/O subsystem 270 is used to control input and output peripherals, which may include other device input controllers, sensor controllers, and display controllers. The processor 280 is a control center of the mobile phone 200, connects various parts of the entire mobile phone using various interfaces and lines, and performs various functions of the mobile phone 200 and processes data by operating or executing software programs and/or modules stored in the memory 220 and calling data stored in the memory 220, thereby performing overall monitoring of the mobile phone. A power supply 290 (e.g., a battery) is used to power the various components described above, and preferably, the power supply may be logically coupled to the processor 280 via a power management system, such that the functions of managing charging, discharging, and power consumption may be performed via the power management system.

In this embodiment, the RF circuit 210 may send and receive information to and from the peer device, and send the received information to the processor 280 for processing. Memory 220 may be used to store software programs and modules for performing the methods of embodiments of the present application. The processor 280 may execute various functional applications of the handset and data processing, such as performing method steps in embodiments of the present application, by executing software programs and modules stored in the memory 220. The display screen 240 may be used to display images of the media player as it plays the media file.

The method and the device can be applied to devices with the Bluetooth working mode of Basic Rate (BR) and Enhanced Data Rate (EDR), and can be applied to Bluetooth technical standards below Bluetooth 5.0 and 5.0, such as Bluetooth 4.2, 4.0 and 3.0.

When the mobile phone is connected to the CT as a TG, the bluetooth Protocol architecture followed by the TG and the CT may be as shown in fig. 3, and includes a Link Manager Protocol (LMP) and a Logical Link Control and adaptation Protocol (L2 CAP), an Audio/Video Control Transport Protocol (AVCTP), a Service Discovery Protocol (SDP), an Audio/Video Remote Control Protocol (AVRCP), and an Application (Application) that can work in parallel.

The LMP is responsible for establishing connection between the Bluetooth devices; the L2CAP and the LMP work in parallel, and when the service data do not pass through the LMP, the L2CAP provides service for an upper layer; the AVCTP protocol describes the format and mechanism of audio/video control signal exchange between bluetooth devices, and is an overall protocol, and specific control information is implemented by its specified protocol (such as AVRCP), and AVCTP itself specifies only the overall format of control commands (command) and responses (response). SDP is the basis for all user modes and can be used to query device information and service types to establish a corresponding connection between bluetooth devices. AVRCP is used to provide a standard interface for controlling devices, i.e., features defining how to control streaming media, including pause, stop, start playback, volume control, and other types of remote control operations; application is the inter-Application communication between the TG and the CT.

Firstly, an Asynchronous Connectionless (ACL) physical link can be established through TG and CT, on the basis, LMP protocol and L2CAP connection are established, TG and CT establish one-to-one or one-to-many connection, then SDP can be used for inquiring equipment information and service types, so that corresponding connection is established between TG and CT, then AVCTP protocol is used for establishing format and mechanism of audio/video control signal exchange between TG and CT, and then ACRCP protocol is used for realizing control signaling interaction between TG and CT.

The AVRCP has multiple service versions, including AVRCP1.0, AVRCP1.3, AVRCP1.4, and AVRCP 1.5. As versions evolve, functionality continues to increase and the link flow differs for each version. When the service version of AVRCP of TG is AVRCP1.4, and the TG and CT establish a bluetooth connection to play a music file in CT, the TG and CT query the service version and the signal interaction between the characteristics between TG and CT through ACRCP as shown in fig. 4, including the following steps.

Step 41, the CT may send an SDP request (SDP request) to the TG first, for requesting to query the AVRCP service version and characteristics of the TG;

step 42, when the AVRCP service version of the TG is AVRCP1.4, the TG replies an SDP response (SDP response) message to the CT, where the SDP response message indicates that the AVRCP service version of the TG is AVRCP1.4, which indicates that the TG supports AVRCP browsing; it should be noted that, from the viewpoint of AVRCP protocol, AVRCP1.3 is not supported for browsing (browsing), and AVRCP1.4 is supported for browsing. If the AVRCP version of a device is 1.3, the device does not support browsing; if an AVRCP version of a device is AVRCP1.4, the device vendor may define that AVRCP1.4 supports browsing or does not support browsing when the device is shipped. The present application is described with the AVRCP version of the device being AVRCP1.4 and AVRCP1.4 supporting browsing. The device supporting browsing in the AVRCP protocol may be understood in this way, where TG is a mobile phone, and CT is an in-vehicle device, if the mobile phone supports browsing, the in-vehicle device side may obtain a list of music players in the mobile phone, where, for example, the list of music players indicates that the music player on the mobile phone side includes QQ music, internet cloud music, and cool dog music, and the in-vehicle device side may further select any music player in the browsing list, and when selecting the music player for browsing internet cloud music, browsing internet cloud music may be understood as: the music folder for browsing the internet music can display song names of a plurality of songs, a plurality of singers, a plurality of music types and the like in a screen of the vehicle-mounted equipment, so that a user can select or search songs to be played in the music folder. Therefore, a user can select a song to be played from the internet music on the mobile phone side and also can select a song to be played from the music folder of the internet music displayed on the vehicle-mounted equipment, when a certain song is played, the mobile phone side only displays the playing progress of the song, the vehicle-mounted equipment side can simultaneously play the song, and lyrics, singer information, song comments, albums of the song and the like of the song being played are displayed on a screen of the vehicle-mounted equipment.

Step 43, when the CT determines that the TG supports AVRCP browsing, the CT sends a get file item request (get folder item request) to the TG to request to get a list of music players of the TG, where the list includes IDs of application programs of multiple music players on the TG side;

step 44, the TG replies to the CT with a get file item response (get folder item response), which includes the list; for example, the IDs of the applications of the plurality of music players in the list include IDs of applications such as QQ music, internet music, and cool dog music, as shown in table 1;

TABLE 1

Music player	ID
		QQ music	00
Internet music	01
		Cool dog music	11
…	…

Step 45, the CT sends a request for browsing the player (set browsed player request) to the GT, wherein the set browsed player request includes the ID of the music player selected by the CT to request to browse the music player in the TG; for example, if the music player selected by the CT is internet cloud music, the set browsed player request includes the ID of the application of the internet cloud music: 01, requesting to browse the internet music; the following steps are explained by taking internet-accessible cloud music as an example.

Step 46, if the internet cloud music in the TG supports browsing, the TG replies a player support browsing response (set browsed player response) to the CT to indicate that the internet cloud music in the CT supports AVRCP browsing; if the internet cloud music in the TG does not support browsing, the TG replies a response that the player does not support browsing (player not browsable) to the CT. Whether the music player supports AVRCP browsing or not can be determined by whether the application program of the music player registers a service supporting AVRCP browsing or not, that is, if the application program of the music player does not register a service supporting AVRCP browsing, the music player does not support ACRCP browsing; or, the music player does not support AVRCP browsing, which is that the audio format supported by the music player is not compatible with CT, for example, the music player supports wav, ogg, mid, and other formats, and CT supports mp3, amr, flac, and the like; or the music player does not support AVRCP browsing, because the Bluetooth protocol of the music player does not support AVRCP, the music player cannot be accessed by the CT; or, the music player does not support AVRCP browsing because the application program of the music player does not support bluetooth for transmitting audio data to CT, etc.

Step 47, if the internet cloud music in the TG supports browsing, the CT may continue to send a browsing command (browsing command for get item attributes) to the TG to obtain song information of the internet cloud music from the TG, and then continue to execute step 48; however, if the internet cloud music does not support browsing, after receiving a response of the player not browsable, the CT does not send browsing command for get item attributes to the TG, but repeatedly sends a set browsed player request to the TG, but the TG does not respond to the set browsed player response to the CT, so that the CT cannot display song information when playing music; taking TG as a mobile phone and CT as a vehicle-mounted device as an example, at this time, an image displayed in a screen of the mobile phone side may be a picture of a music player requested to be browsed by the vehicle-mounted device, and when receiving a player not browsable response, the vehicle-mounted device side may display prompt information indicating that acquisition of song information fails, for example, the prompt information may be: "failed to acquire song information" or "unknown", or the like, or no prompt information is displayed in the screen, i.e., a black screen state. Fig. 4A is a schematic screen display diagram of the mobile phone and the vehicle-mounted device when the mobile phone sends a player not browsable response to the vehicle-mounted device.

And step 48, the TG replies a response (response for get item attributes) for acquiring the item attributes to the CT, wherein the response for get item attributes carries the song information of the Internet cloud music. Taking TG as a mobile phone and CT as a vehicle-mounted device as an example, as shown in fig. 4B, an image displayed in a screen of the mobile phone side may be a picture of a music player requested to be browsed by the vehicle-mounted device, and when receiving song information of the internet music, the vehicle-mounted device side may display a song name of a song of the internet music, a player name of the internet music, a singer of the song, and the like in the screen of the vehicle-mounted device side.

For example, if the CT is the car device and the TG is the mobile phone, when the mobile phone is connected to the car system via bluetooth technology to play music in the mobile phone, the car device may first query the service version and features of the mobile phone, when the AVRCP version replied by the mobile phone is AVRCP1.4, the mobile phone supports AVRCP browsing, the vehicle-mounted system can continuously send a set _ browsed _ player request command carrying the identification of the internet accessible cloud music to the mobile phone to request for browsing the song information of the internet accessible cloud music, when the internet cloud music application program in the mobile phone does not support AVRCP browsing, the mobile phone replies a player _ not _ browse response to the vehicle-mounted system, indicating that the internet music does not support AVRCP browsing, at the moment, the vehicle-mounted system does not send a request for acquiring song information to the mobile phone any more, but a set _ browsed _ playterrequest command is repeatedly sent to the mobile phone, so that the vehicle-mounted system cannot display song information when playing music files of the internet-accessible cloud music in the mobile phone.

As shown in fig. 5, if the CT sends an SDP request to the TG to request to query the AVRCP service version and characteristics of the TG, when the AVRCP service version of the TG is AVRCP1.3, the SDPresponse replied by the TG indicates that the AVRCP service version of the TG is AVRCP1.3, and the AVRCP1.3 version does not support AVRCP browsing, then the CT sends a get element attributes command (get element attributes command) directly to the TG to obtain song information of the music player at the TG end, and the TG sends a get element attributes response (get element attributes response) to the CT to send the song information to the CT.

Therefore, the service versions of AVRCP of TG carried in SDP response message replied by TG to CT are different, and the subsequent behavior of CT is also different, i.e. the link established by TG and CT is different. Wherein, get element attributes command and get element attributes response belong to the command of get element attributes, browse command for get element attributes and response for get element attributes belong to the command of get element attributes, the commands of get element attributes and get element attributes are all used for obtaining song information, the difference lies in that the fields of the song information required to be obtained are different, and the song information replied in the corresponding response is also different.

Aiming at the problem that the CT is connected with the TG Bluetooth to play music files in the TG, and a music player in the TG does not support browsing, so that the CT cannot display song information, the application provides a method for dynamically adjusting the AVRCP version, as shown in FIG. 6, which comprises the following steps:

601. the terminal device responds to a first SDP request message sent by the opposite terminal device, and sends a first SDP response message to the opposite terminal device, wherein the first SDP response message carries the version number of the first AVRCP version.

The terminal device may be a TG, the peer device may be a CT, for example, the TG is a mobile phone having a bluetooth function and equipped with music playing and supporting AVRCP, the CT is a vehicle-mounted device having a bluetooth function and equipped with music playing and supporting AVRCP, and in a process that the mobile phone establishes a bluetooth connection with the vehicle-mounted device so that the vehicle-mounted device plays a music file in a music player of the mobile phone, if the mobile phone receives an SDP request sent by the vehicle-mounted device and an AVRCP version supported by the mobile phone is AVRCP1.4, the mobile phone replies that the AVRCP version supported by the mobile phone is AVRCP1.4 in a first SDP response of the vehicle-mounted device, that is, a version number of the first AVRCP version is AVRCP 1.4.

602. The terminal equipment responds to at least two browsing request messages sent by the opposite terminal equipment, and the browsing request messages are used for requesting the opposite terminal equipment to request to display the media information of the media player.

According to the interaction flow of fig. 4, for example, when the vehicle-mounted device knows that the mobile phone supports AVRCP1.4, it determines that the mobile phone supports AVRCP browsing, and then continuously sends a set browsed player request to the mobile phone, where the set browsed player request includes an ID of a music player selected by the vehicle-mounted device to request to browse the music player in the mobile phone, and if the music player in the mobile phone does not support browsing, the mobile phone replies a player not browsable response to the vehicle-mounted device to indicate that the music player does not support browsing, then the vehicle-mounted device repeatedly sends the set browsed player request to the mobile phone, but does not send browsed command for get item entries to the mobile phone, so that the vehicle-mounted device cannot display songs, and thus the mobile phone may recognize that the operation of the vehicle-mounted device repeatedly sending the set browsed player request as an abnormal operation or speaking occurs when the vehicle-mounted device requests to browse a media player, it is recognized that a specific behavior exists when the vehicle-mounted device requests to browse the media player.

603. And the terminal equipment responds to a second SDP request message sent by the opposite terminal equipment, wherein the second SDP request message is sent when the terminal equipment is disconnected from the opposite terminal equipment and then is connected again, a second SDP response message is sent to the opposite terminal equipment, the second SDP response message carries the version number of a second AVRCP version, and the version number of the second AVRCP version is lower than that of the first AVRCP version.

For example, when the mobile phone recognizes that the vehicle-mounted device has abnormal operation, if the mobile phone disconnects the bluetooth connection with the vehicle-mounted device, and the bluetooth connection is re-established so that the vehicle-mounted device plays the music file in the music player of the mobile phone, if the mobile phone receives an SDP request sent by the vehicle-mounted device, then the mobile phone may indicate that the version of AVRCP supported by the mobile phone is AVRCP1.3 in SDP response sent by the vehicle-mounted device, that is, the version number of the second version of AVRCP is AVRCP 1.3. The version number of AVRCP1.3 is lower than the version number of AVRCP 1.4. In this way, the link between the mobile phone and the vehicle-mounted device is different from the link for establishing the bluetooth connection last time, and the operation for establishing the bluetooth connection between the mobile phone and the vehicle-mounted device at this time can be as shown in fig. 5, so that the vehicle-mounted device does not send the set bridged player request to the mobile phone, and abnormal operation that the vehicle-mounted device repeatedly sends the set bridged player request to the mobile phone does not occur.

Thus, according to the embodiment shown in fig. 6 of the application, when the mobile phone is connected with the vehicle-mounted device in a bluetooth pairing manner to play music, the mobile phone can recognize the abnormal behavior that the vehicle-mounted device repeatedly sends the set browsed player request, when the mobile phone is disconnected from the vehicle-mounted device and then connected again, when the vehicle-mounted device sends the SDP request to query the AVRCP version at the mobile phone side, the first AVRCP version originally supported by the mobile phone is reduced to the second AVRCP version, so that the abnormal behavior of the vehicle-mounted device when the first AVRCP version is replied to the vehicle-mounted device is avoided, the second AVRCP version does not support AVRCP browsing, the vehicle-mounted device can send get element entries to the mobile phone to obtain song information, and the problem that the vehicle-mounted device cannot display song information due to the fact that the vehicle-mounted device continuously sends the set browsed player request to the mobile phone again next time is avoided.

The following further describes the embodiment of the present application with the terminal device as a mobile phone and the peer device as a vehicle-mounted device, and as shown in fig. 7, the method of the embodiment of the present application may include:

701. the vehicle-mounted equipment sends an SDP request, namely an SDP request to the mobile phone so as to inquire the AVRCP version of the mobile phone.

In the process of establishing the bluetooth connection between the vehicle-mounted device and the mobile phone, if the vehicle-mounted device wants to play a music file of a music player in the mobile phone, the vehicle-mounted device needs to send an SDP request to the mobile phone to query the AVRCP version of the mobile phone, so that the vehicle-mounted device can determine a standard interface for operation when playing the music file according to the AVRCP version of the mobile phone, that is, how to control the characteristics of the music file, including pause, stop, start playback, volume control, other types of remote control operations, and the like. The AVRCP version may be one of the aforementioned exemplary AVRCP1.0, AVRCP1.3, AVRCP1.4, and AVRCP1.5, among others.

702. The mobile phone sends a first SDP response, namely a first SDP response, to the vehicle-mounted device, wherein the first SDP response carries a version number AVRCP1.4 of the first AVRCP version.

If the AVRCP version of the handset is AVRCP1.4, the flow shown in fig. 4 may be continued.

703. The vehicle-mounted equipment sends a file item acquisition request, namely get folder item request to the mobile phone to request to acquire a list of media players in the mobile phone.

Each media player corresponds to an ID.

704. The mobile phone sends a response of acquiring the file item, namely a get folder item response, to the vehicle-mounted device, wherein the get folder item response comprises a list of media players in the mobile phone.

705. The vehicle-mounted equipment sends a browsing request message to the mobile phone, namely the browsing request message is used for requesting to browse the player.

Requesting to browse the player may be understood as requesting to browse music files in the music player, including song information such as the singer, the duration of the song, the name of the song, and the like. The browsing request message includes the ID of the media player requested by the in-vehicle device.

706. And the mobile phone sends a browsing response message to the vehicle-mounted equipment, wherein the browsing response message is used for indicating that the player does not support browsing.

If the music player in the mobile phone does not support browsing through the bluetooth protocol or the version of the music player is too low to support browsing, as can be seen from the description of fig. 4, the mobile phone may send a response that does not support browsing, i.e., a response of the player not browsable, to the vehicle-mounted device.

707. If the mobile phone receives at least N browsing request messages sent by the vehicle-mounted equipment within a preset time period, the mobile phone determines that the vehicle-mounted equipment has abnormal operation, or determines that the vehicle-mounted equipment cannot display media information of the player. N is a positive integer.

As can be seen from the description of fig. 4, if the vehicle-mounted device receives a response of the player not browsable sent by the mobile phone, it will not continue to send browsable command for get item attributes to the TG, but will repeatedly send a set browsable player request to the mobile phone, and if the preset time period here is 1s and N is 3, that is, if the mobile phone receives at least 3 browsing request messages launched by the vehicle-mounted device within 1s, the mobile phone will determine that the vehicle-mounted device has an abnormal operation, or that the mobile phone determines that the vehicle-mounted device has a specific behavior. N may also be other values, and the application is not limited. That is to say, in the embodiment of the present application, a mechanism for identifying a specific behavior of a peer device of a mobile phone is added on the mobile phone side.

708. And the mobile phone records the equipment information of the vehicle-mounted equipment in a preset equipment information set.

In one possible implementation, the device information of the vehicle-mounted device may include bluetooth information of the vehicle-mounted device, or the device information of the vehicle-mounted device includes bluetooth information and a device type of the vehicle-mounted device.

The Bluetooth information is the first three digits of the Bluetooth address of the vehicle-mounted device, or the Bluetooth information is the Bluetooth name of the vehicle-mounted device, or the Bluetooth information is the first three digits of the Bluetooth address of the vehicle-mounted device and the Bluetooth name. The first three digits of the bluetooth address are recorded here because: the bluetooth address of a device has six bits: XX: XX: XX: XX: XX: XX, the bluetooth address of each device is different, i.e. the bluetooth address is different for different devices, if six bits of the bluetooth address of a device are recorded, it is only marked that this one device has a certain behavior, while the first three digits of a bluetooth address can mark the manufacturer of the device or the manufacturer of the bluetooth chip used by the device, if a device of a manufacturer has a specific behavior, in order for the device to conveniently obtain song information of the device to be connected with the Bluetooth through the device of the manufacturer or the Bluetooth chip, the manufacturer of the device or bluetooth chip may be recorded in a preset device information set, so that once the device information of the bluetooth chip or a device of the device manufacturer is recorded in the preset device information set, it can be considered that the specific behavior exists in the bluetooth chip or the device of the device manufacturer. Therefore, only the first three digits of the bluetooth address may be stored in the preset device information set.

Accordingly, the preset device information set includes bluetooth information of at least one device or bluetooth information and device type of at least one device, or the preset device information set is empty, i.e., the set is initially empty before device information is not recorded.

In another possible implementation, step 708 may also be replaced by: and the mobile phone sets the content of the AVRCP version field corresponding to the vehicle-mounted equipment in the Bluetooth pairing file as the version number of the second AVRCP version. For example the version number of the second version of AVRCP may be AVRCP 1.3. The bluetooth pairing file may be a bt _ config.conf file, where the bt _ config.conf file is used to record device information of a device that has already established bluetooth pairing with a mobile phone, and a field AVRCP version, that is, an AVRCP version field, is newly added in the bt _ config.conf file, where the field indicates a version number of a second AVRCP version of the mobile phone carried by the mobile phone when the mobile phone replies an SDP response to the device that has established bluetooth pairing with the mobile phone, for example, a content of an onboard device in the bt _ config.conf file under the field is AVRCP1.3, and indicates that when the mobile phone sends an SDP response to the onboard device, a version number of the AVRCP version of the mobile phone should be replied to the onboard device is AVRCP 1.3. The Bluetooth pairing file can also be a new file on the mobile phone side, and the new file comprises an AVRCP version field.

709. And the mobile phone receives the SDP request message sent by the vehicle-mounted equipment again.

Here, the receiving of the SDP request message again may be understood as that, after the bluetooth connection between the mobile phone and the vehicle-mounted device is disconnected after step 708, the mobile phone receives the SDP request message sent by the vehicle-mounted device when the bluetooth connection is established again.

710. The mobile phone queries whether the device information of the vehicle-mounted device is in a preset device information set, and if the device information of the vehicle-mounted device is in the preset device information set, the mobile phone determines to send a second SDP response message to the vehicle-mounted device, wherein the second SDP response message carries a version number of a second AVRCP version, and the version number of the second AVRCP version is lower than that of the first AVRCP version. Then, step 711 is performed. And if the device information of the vehicle-mounted device is not in the preset device information set, returning to the step 702 to continue execution.

If the device information is the first three digits of the bluetooth address of the vehicle-mounted device, and the mobile phone queries that the first three digits of the bluetooth address of the vehicle-mounted device are in the preset device information set, the mobile phone determines to send a second SDP response message to the vehicle-mounted device, wherein the second SDP response message carries a version number of a second AVRCP version, namely, ACRCP1.3, and ACRCP1.3 is lower than ACRCP 1.4.

Alternatively, according to another possible implementation of step 708, step 710 may be replaced by: and the mobile phone queries the content of the AVRCP version field corresponding to the vehicle-mounted equipment in the Bluetooth pairing file as the version number of the second AVRCP version.

711. And the mobile phone sends a second SDP response message to the vehicle-mounted equipment.

The second SDP response message carries the version number of the second AVRCP version, that is, ACRCP1.3, that is, the mobile phone notifies the vehicle-mounted device that the ACRCP version at the mobile phone side is ACRCP 1.3.

The second SDP response message also includes characteristics supported by the second AVRCP version. Compared with the first SDP response message replied last time, the second SDP response message replied to the vehicle-mounted device when the mobile phone side establishes bluetooth connection with the vehicle-mounted device this time changes the version number of the ACRCP version at the mobile phone side, and accordingly, the mobile phone side can inform the vehicle-mounted device of the characteristics supported by the changed second ACRCP version ACRCP 1.3.

Correspondingly, the method may further include: the mobile phone updates the characteristic of the first AVRCP version in the mobile phone to the characteristic of the second AVRCP version, that is, the mobile phone updates the field and the content of the field corresponding to the characteristic of the ACRCP1.4 in the mobile phone to the field and the content of the field of the ACRCP 1.3.

712. And the vehicle-mounted equipment sends an element attribute obtaining command, namely the sent get element attributes command to the mobile phone so as to obtain the media file information of the mobile phone player.

From the flow of fig. 5, if the SDP response message returned by the mobile phone to the vehicle-mounted device indicates that the version number of the ACRCP version of the mobile phone is ACRCP1.3, the vehicle-mounted device does not execute step 703 when the bluetooth connection is established last time when receiving the SDP response message, but sends an acquire element attribute command to the mobile phone to acquire media file information of a player of the mobile phone, for example, the media file information may be song information of a music player.

713. The mobile phone sends an element attribute obtaining response, namely the sent get element attributes response, to the vehicle-mounted device, and the element attribute obtaining response comprises media file information.

Therefore, in the process of establishing the bluetooth connection between the mobile phone and the vehicle-mounted device, once the mobile phone side recognizes that the vehicle-mounted device has abnormal operation or a specific behavior, when the mobile phone is disconnected from the vehicle-mounted device and then connected again, and when the vehicle-mounted device queries the AVRCP version at the mobile phone side, the version number of the AVRCP version that the mobile phone can reply to the vehicle-mounted device is lower than the version number of the last connection, and the link behavior of the mobile phone and the vehicle-mounted device is different under different version numbers, for example, when the version number of the AVRCP version is avcp 1.4, the link behavior is as shown in fig. 4, and when the version number of the AVRCP version is ACRCP1.4, the link behavior is as shown in fig. 5, so that the problem that the vehicle-mounted device cannot display song if the music player at the mobile phone side does not support browsing in fig. 4 is avoided.

Fig. 8 shows a schematic structural diagram of a chip provided in the present application.

The Chip may be a System-on-a-Chip (SoC) 80, which may also be referred to as a System-on-Chip, and is an integrated circuit with a dedicated target, including the complete System and having the entire contents of embedded software. From a narrow sense, the SoC is the chip integration of the information system core, and is to integrate the key components of the system on one chip; in a broad sense, the SoC is a micro-miniature system. SoC is generally defined as integrating a microprocessor or core (core)81, an analog Intellectual Property core (IP core) 82, a digital IP core 83, and a memory (or off-chip memory control interface) 84 on a single chip.

A Core81, such as a Core of a Central Processing Unit (CPU), i.e., an Arithmetic Logic Unit (ALU), for running instructions in the memory 84 of the SoC and processing data in software, etc.;

the memory 84 includes various volatile, nonvolatile, and Cache memories;

analog IP core 82 and digital IP core 83, some of the functional blocks that are commonly used in digital circuits, but are more complex, may be designed as modules that can modify parameters. Such as Finite Impulse Response (FIR) filters, Synchronous Dynamic Random Access Memory (SDRAM) controllers, Peripheral Component Interconnect (PCI) interfaces, and the like.

In this embodiment, the SoC80 may cooperate with the bluetooth chip 85 to implement the technical solution of this application, for example, both the SoC80 and the bluetooth chip 85 are designed on a motherboard circuit of the TG, the Memory 84 in the SoC80 stores programs and data for executing the method steps of this embodiment, for example, the programs and data are specifically stored in a Read-Only Memory (ROM) of the SoC80, and the core81 may run the programs and data of the method steps stored in the ROM.

Taking TG as a mobile phone and TC as an example of a vehicle-mounted device, when the mobile phone is connected with the vehicle-mounted device in a bluetooth manner, a bluetooth chip 85 in the mobile phone receives an SDP request, a browsing request message and the like sent by a CT through a bluetooth protocol, and transmits the SDP request and the browsing request message to an SoC80 for processing, and the SoC80 can send an SDP response, a browsing response message and the like to the CT through the bluetooth chip 85. When the SoC80 receives at least two browsing request messages, it can be recognized that the vehicle-mounted device cannot display media information, the device information of the vehicle-mounted device can be recorded in the memory 84, when the mobile phone is disconnected from the vehicle-mounted device and then connected again, when the SoC80 receives an SDP request message sent by the vehicle-mounted device through the bluetooth chip 85, the SoC80 can inquire that the device information of the vehicle-mounted device is recorded in the memory 84, and the SoC80 determines that an AVRCP version number with the AVRCP version reduced is sent to the vehicle-mounted device through the bluetooth chip 85, so that the link behavior of the vehicle-mounted device and the mobile phone is changed, and the problem that the vehicle-mounted device cannot display media information is avoided.

Fig. 9 shows a schematic structural diagram of a terminal device provided in the present application.

A terminal device can be called an access terminal, UE, subscriber unit, subscriber station, mobile, remote station, remote terminal, mobile device, user terminal, wireless communication device, user agent, or user equipment. An access terminal may be a cellular telephone, a handheld device with wireless communication capabilities, a computing device or other processing device connected to a wireless modem, an in-vehicle device, a wearable device, and a user equipment in a fifth Generation mobile communication technology (5-Generation, 5G) communication system. The above electronic devices are only examples of the terminal device, and the terminal device may also be other electronic devices, such as a mobile phone and a Pad that include the SoC80 and the bluetooth chip 85.

As shown in fig. 9, when the terminal device is a mobile phone, the mobile phone 90 includes an SoC80, a bluetooth chip 85, a control circuit, an antenna, and an input/output device. The SoC80 is mainly used for processing communication protocols and communication data, controlling the entire terminal device, executing software programs, and processing data of the software programs. The bluetooth chip 85 may be used to communicate with a peer device via a bluetooth protocol. The control circuit is mainly used for converting baseband signals and radio frequency signals and processing the radio frequency signals. The control circuit and the antenna together, which may also be called a transceiver, are mainly used for transceiving radio frequency signals in the form of electromagnetic waves. Input and output devices, such as touch screens, display screens, or keyboards, are used primarily for receiving data input by a user and for outputting data to the user.

Those skilled in the art will appreciate that fig. 9 shows only one processor (SoC80) for ease of illustration. In an actual terminal device, there may be a plurality of processors.

As shown in fig. 10, an embodiment of the present application further provides a terminal device 10, where the terminal device includes a memory 100, a processor 102, a transceiver 103, and a display 104, the memory 100 stores instructions, and the memory 100, the processor 102, the transceiver 103, and the display 104 are connected to each other through a bus 105; the bus 105 may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 10, but this is not intended to represent only one bus or type of bus. The display 104 may be used to display images of a media player, etc.

The instructions, when executed by the processor 102, cause the terminal device 10 to perform the following operations:

responding to a first Service Discovery Protocol (SDP) request message sent by opposite-end equipment, and sending a first SDP response message to the opposite-end equipment, wherein the first SDP response message carries a version number of a first AVRCP version;

responding at least two browsing request messages sent by opposite terminal equipment, wherein the browsing request messages are used for requesting the opposite terminal equipment to display the media information of the media player, and sending a browsing response message corresponding to each browsing request message to the opposite terminal equipment, and the browsing response messages indicate that the media player does not support the opposite terminal equipment to request to display the media information of the media player;

recording the equipment information of the opposite terminal equipment in a preset equipment information set;

responding to a second SDP request message sent by the opposite terminal equipment, wherein the second SDP request message is sent when the terminal equipment is disconnected with the opposite terminal equipment and then is connected again, and inquiring whether the equipment information of the opposite terminal equipment is in a preset equipment information set or not; if the equipment information of the opposite terminal equipment is in the preset equipment information set, sending a second SDP response message to the opposite terminal equipment; the second SDP response message carries the version number of the second AVRCP version, and the version number of the second AVRCP version is lower than that of the first AVRCP version.

The specific implementation of this operation may refer to the description in the embodiment in fig. 6 or fig. 7, and is not described in detail in this application.

The operations may further include: and if the equipment information of the opposite terminal equipment is not in the preset equipment information set, sending a first SDP response message to the terminal equipment.

The device information of the opposite terminal device comprises Bluetooth information of the opposite terminal device, or the device information of the opposite terminal device comprises Bluetooth information and a device type of the opposite terminal device; the Bluetooth information is the first three digits of the Bluetooth address of the opposite terminal equipment, or the Bluetooth information is the Bluetooth name of the opposite terminal equipment, or the Bluetooth information is the first three digits of the Bluetooth address of the opposite terminal equipment and the Bluetooth name; the preset device information set comprises the Bluetooth information of at least one device or the Bluetooth information and the device type of at least one device, or the preset device information set is empty.

It should be noted that the second SDP response message further includes a characteristic supported by the second AVRCP version; accordingly, the operations may further include: and updating the characteristics of the first AVRCP version to the characteristics of the second AVRCP version in the terminal equipment.

The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A method for dynamically adjusting the version of audio/video remote control protocol (AVRCP) is applied to a terminal device, the terminal device comprises a media player, and the method comprises the following steps:

the method comprises the steps that a terminal device responds to a first Service Discovery Protocol (SDP) request message sent by an opposite terminal device, and sends a first SDP response message to the opposite terminal device, wherein the first SDP response message carries a version number of a first AVRCP version;

the terminal equipment responds to at least two browsing request messages sent by the opposite terminal equipment, wherein the browsing request messages are used for the opposite terminal equipment to request to display the media information of the media player;

and the terminal device responds to a second SDP request message sent by the opposite terminal device, wherein the second SDP request message is sent when the terminal device is disconnected from the opposite terminal device and then is connected again, and a second SDP response message is sent to the opposite terminal device, and carries a version number of a second AVRCP version, and the version number of the second AVRCP version is lower than that of the first AVRCP version.

2. The method of claim 1, wherein the version number of the first version of AVRCP is AVRCP1.4 and the version number of the second version of AVRCP is AVRCP 1.3.

3. The method according to claim 1 or 2, wherein when the terminal device receives one of the browse request messages, the method further comprises:

and the terminal equipment sends a browse response message to the opposite terminal equipment, wherein the browse response message indicates that the media player does not support the opposite terminal equipment to request to display the media information of the media player.

4. The method according to claim 1, wherein if the terminal device receives at least two of the browsing request messages, the method further comprises:

the terminal equipment records the equipment information of the opposite terminal equipment in a preset equipment information set;

before the terminal device sends the second SDP response message to the peer device, the method further includes:

the terminal equipment inquires whether the equipment information of the opposite terminal equipment is in the preset equipment information set or not;

and if the device information of the opposite terminal device is in the preset device information set, the terminal device determines to send the second SDP response message to the opposite terminal device.

5. The method of claim 4, further comprising:

and if the equipment information of the opposite terminal equipment is not in the preset equipment information set, the terminal equipment sends the first SDP response message to the terminal equipment.

6. The method according to claim 5, wherein the device information of the peer device comprises bluetooth information of the peer device, or the device information of the peer device comprises bluetooth information and a device type of the peer device;

the preset device information set comprises Bluetooth information of at least one device or Bluetooth information and a device type of at least one device, or the preset device information set is empty.

7. The method of claim 6, wherein the Bluetooth information is the first three digits of the Bluetooth address of the peer device, or the Bluetooth information is the Bluetooth name of the peer device, or the Bluetooth information is the first three digits and the Bluetooth name of the Bluetooth address of the peer device.

8. The method according to claim 1, wherein if the terminal device receives at least two of the browsing request messages, the method further comprises:

the terminal device sets the content of the AVRCP version field corresponding to the opposite terminal device in a Bluetooth pairing file as the version number of the second AVRCP version, the Bluetooth pairing file comprises device information of the opposite terminal device performing Bluetooth pairing with the terminal device, and the device information comprises the AVRCP version field corresponding to the opposite terminal device.

9. The method of claim 1, wherein the second SDP response message further comprises a characteristic supported by the second AVRCP version;

the method further comprises the following steps:

and the terminal equipment updates the characteristic of the first AVRCP version in the terminal equipment to the characteristic of the second AVRCP version.

10. The method of claim 1, wherein the media information comprises song information, and wherein the song information comprises a song name, a song quantity, song lyrics, and a song playing time length.

11. A terminal device comprising a memory, a processor, a transceiver, and a display, the memory storing instructions that, when executed by the processor, cause the terminal device to:

responding at least two browsing request messages sent by the opposite terminal equipment, wherein the browsing request messages are used for the opposite terminal equipment to request to display the media information of a media player, and sending a browsing response message corresponding to each browsing request message to the opposite terminal equipment, wherein the browsing response message indicates that the media player does not support the opposite terminal equipment to request to display the media information of the media player;

responding to a second SDP request message sent by the opposite terminal equipment, wherein the second SDP request message is sent when the terminal equipment is disconnected from the opposite terminal equipment and then is connected again, and inquiring whether the equipment information of the opposite terminal equipment is in the preset equipment information set; if the device information of the opposite terminal device is in the preset device information set, sending a second SDP response message to the opposite terminal device; the second SDP response message carries a version number of a second AVRCP version, and the version number of the second AVRCP version is lower than that of the first AVRCP version.

12. The terminal device of claim 11, wherein the version number of the first AVRCP version is AVRCP1.4 and the version number of the second AVRCP version is AVRCP 1.3.

13. The terminal device of claim 11 or 12, wherein the operations further comprise:

and if the equipment information of the opposite terminal equipment is not in the preset equipment information set, sending the first SDP response message to the terminal equipment.

14. The terminal device according to claim 11, wherein the device information of the peer device includes bluetooth information of the peer device, or the device information of the peer device includes bluetooth information and a device type of the peer device;

15. The terminal device of claim 14, wherein the bluetooth information is the first three digits of the bluetooth address of the peer device, or the bluetooth information is the bluetooth name of the peer device, or the bluetooth information is the first three digits of the bluetooth address of the peer device and the bluetooth name.

16. The terminal device of claim 11, wherein the second SDP response message further comprises characteristics supported by the second AVRCP version;

the operations further include: and updating the characteristic of the first AVRCP version in the terminal equipment to the characteristic of the second AVRCP version.

17. The terminal device of claim 11, wherein the media information comprises song information, and the song information comprises a song name, a song quantity, song lyrics, and a song playing time length.

18. A chip, characterized in that the chip comprises a memory and a processor, the memory storing instructions that, when executed by the processor, cause the chip to perform the method according to any of claims 1-10.

19. A terminal device, characterized in that the terminal device comprises a memory storing computer instructions that, when executed, cause the terminal device to perform the method according to any of claims 1-10.

20. A computer storage medium having computer instructions stored thereon which, when executed by a computer, cause the computer to perform the method of any one of claims 1-10.