Hi, i've develop an application on Android 11 with link-os SDK 2.14.5198 for print ticket on zd410 and connect it with bluetooth.
The progam senda data, open connection, print 1 title, close connection and repeat the operation x time in function of the number of tickets.
Random when i print more 2 or 3 or 4 ticket the system can generate an connectione exception with this code:
2022-04-13 17:20:55.068 5245-5811/? I/bt_stack: [INFO:btsnoop.cc(544)] clear_l2cap_whitelist: Clearing whitelist from l2cap channel. conn_handle=10 cid=80:0
2022-04-13 17:20:55.068 5245-5811/? W/bt_l2cap: l2cu_no_dynamic_ccbs starting IDLE timeout: 30000 ms
2022-04-13 17:20:55.068 5245-5811/? W/bt_rfcomm: PORT_StartCnf: failed result:5
2022-04-13 17:20:55.069 5245-5853/? E/bt_btif_sock_rfcomm: find_rfc_slot_by_id unable to find RFCOMM slot id: 11
2022-04-13 17:20:55.069 5245-5811/? E/bt_btm: Reset sec_bd_name and name flag. (BR/EDR link)
2022-04-13 17:20:55.073 5245-5811/? W/bt_btif: BtifAvPeer *BtifAvSource::FindOrCreatePeer(const RawAddress &, tBTA_AV_HNDL, uint32_t): Create peer: peer_address=48a493 bta_handle=0x41 peer_id=0
2022-04-13 17:20:55.074 5245-5811/? W/bt_btif: virtual bool BtifAvStateMachine::StateIdle::ProcessEvent(uint32_t, void *): Peer 48a493 : event=BTIF_AV_ACL_DISCONNECTED(0x23)
2022-04-13 17:20:55.074 5245-5811/? W/bt_btif: DeleteIdlePeers: Deleting idle peer: 48a493 bta_handle=0x41
2022-04-13 17:20:55.077 11192-19911/it.sistemiterritorialispa.vendita D/ticket -: Could not connect to device: read failed, socket might closed or timeout, read ret: -1
And the ticket is not printed.
I've paring the printer with pin using android settings interface and this is the value of zd410 parameter:
bluetooth.
bluetooth.discoverable : off , Choices: on,off
bluetooth.friendly_name : ZD410AB
bluetooth.version : 6.0.1
bluetooth.date : 12/05/2018
bluetooth.local_name : ZD410AB
bluetooth.address : 48:XX:XX:XX:XX:XX
bluetooth.bluetooth_pin : *
bluetooth.short_address : 48XXXXXX
bluetooth.radio_version : 4.2
bluetooth.enable : on , Choices: on,off
bluetooth.connected : no
bluetooth.minimum_security_mode : 4 , Choices: 1,2,3,4
bluetooth.connected_security_mode : nc
bluetooth.bonding : on , Choices: on,off
bluetooth.clear_bonding_cache
bluetooth.enable_reconnect : off , Choices: off,iOS_only
bluetooth.allow_non_display_numeric_comparison : no print , Choices: off,print,no print
bluetooth.le.
bluetooth.le.controller_mode : classic , Choices: both,classic,le
bluetooth.json_config_channel_enable : on , Choices: on,off
bluetooth.page_scan_window : 60 , Choices: 15,60
bluetooth.power_class : 1 , Choices: 1-2
In the code i've create the class BluetoothSecureConnection in this way:
public class BluetoothSecureConnection {
private boolean sendData = true;
Connection printerConnection = null;
public static int startPrint(String macValue, String dataPass, String type, String url, String printerType) {
int Status = 0;
BluetoothSecureConnection connSC = new BluetoothSecureConnection();
Status = connSC.connectAndSendLabel(macValue, dataPass, type, url, printerType);
return Status;
}
And in the connect and sendLabel i create the connection:
private int connectAndSendLabel(final String mac, String dataPass, String type, String url, String printerType) {
printerConnection = new BluetoothConnection(mac);
int Status = 0;
try {
printerConnection.open();
ZebraPrinter printer = null;
if (printerConnection.isConnected()) {
I've change the printer with another with the same setting but random the problem exist.
So what i've to modify to resolve this problem or thereis the possibilituy to reopen connection if is close?
Thanks
3 Replies
With the partial code snippet, it's difficult to say where the issue is. In general, the recommended logic flow is:
If we use the above flow for each label print, then the connection open & close for each label may pose some overhead. Otherwise, we can send multiple labels at the step 4 with just one iteration of the connection open & close.
Thanks for the answer .. for how the program is built I have to keep the opening and closing of the connection for each ticket otherwise the whole app and logic are upset.
So if I introduce a 500 ms waiting time before reopening the connection in the next title, could this be enough to eliminate the opening exception?
I cannot say that for sure if 500ms is enough. You will have to test if that works for you depending on the data size of each ticket. It's also depending on the UI flow of the app. You may want to keep the connection open in one particular UI view, so that the user can print multiple tickets in that UI view without the need to open & close for each individual ticket. You may only close the connect when the user navigate away from the particular UI view.