這是發(fā)表在電子產(chǎn)品世界2009精選實用電子設(shè)計100例上的文章，論述了藍牙技術(shù)的兼容性問題出現(xiàn)的原因以及解決方法。
引言
藍牙技術(shù)問世10余年，得到了廣泛應(yīng)用，其中部分原因在于藍牙SIG組織為各種應(yīng)用以profile的形式定義了應(yīng)用協(xié)議，這樣藍牙設(shè)備之間的互操作便有章可循，但即使如此，藍牙設(shè)備之間的互操作性又稱兼容性問題仍存在于幾乎所有藍牙應(yīng)用中。筆者歷時兩年時間為某合資汽車廠商開發(fā)了一款藍牙車載產(chǎn)品，實現(xiàn)了免提通話、雙重呼叫管理、電話本自動下載與手動下載、流媒體音樂播放及遠程控制功能，期間測試了近100部手機和音樂播放器，遇到并解決了各種兼容性問題。結(jié)合產(chǎn)品開發(fā)過程中測試并解決兼容性問題的經(jīng)驗，本文對兼容性問題出現(xiàn)的原因進行了分析，大致有以下三個方面的原因：具體應(yīng)用本身定義不嚴格、應(yīng)用上下文差異、引入?yún)f(xié)議帶來的兼容性。以下就這三個方面進行詳細分析并結(jié)合具體實例，說明其解決方法。
應(yīng)用定義不嚴格
藍牙SIG組織定義了Profile，對各種功能的實現(xiàn)方式做了規(guī)范，并且定義了必選功能和可選功能，設(shè)備廠商可以對可選項有選擇得實現(xiàn)，這樣便會造成一定的差異。而且Profile并沒有對應(yīng)用本身做嚴格定義，只是定義了功能，而應(yīng)用是功能的集合體，Profile并沒有定義怎么由多個功能組合實現(xiàn)某個應(yīng)用，這樣藍牙設(shè)備廠商在實現(xiàn)某一應(yīng)用時便有了差異性。雙重呼叫是車載設(shè)備免提通話應(yīng)用中兼容性最多的一種應(yīng)用，下面分析下該應(yīng)用出現(xiàn)兼容性問題的原因并舉例剖析其解決方法。
對于免提通話而言，比較重要的幾個功能是呼叫建立提示CALL_SETUP、呼叫保持CALL_HELD、呼叫結(jié)果CALL、呼叫信息CLCC，手機在呼叫狀態(tài)產(chǎn)生變化時實時向免提設(shè)備端傳送這些提示消息，免提設(shè)備端便可以與手機的呼叫狀態(tài)保持一致，在免提設(shè)備端控制呼叫才符合預(yù)期。其中CALL_SETUP和CALL是必選功能，但對于雙重呼叫而言非常重要的CALL_HELD和CLCC卻是可選功能，雙重呼叫在免提剖面HFP（Hands-Free Profile）中定義為Three way calling，這也是一個可選功能。這樣在支持雙重呼叫時，各種手機便以自己的方式來支持或者部分支持，這樣便來了雙重呼叫的兼容性問題。下面以第二個呼叫為呼出為例剖析下解決方法。
當(dāng)撥打第二個電話時，手機會發(fā)送CALL_SETUP=2消息，表示正在呼出，結(jié)果有對方拒接、對方接聽、未撥通這么幾種情況。顯然判斷出呼出結(jié)果是至關(guān)重要的，我們通過對手機進行測試然后根據(jù)其表現(xiàn)特性進行分類，將手機分為如下幾類：A-支持CALL_HELD不支持CLCC、B-支持CALL_HELD和CLCC、C-支持CLCC不支持CALL_HELD而且手機在Three way calling下不支持CALL、D-支持CLCC不支持CALL_HELD但手機在Three way calling下支持CALL、E-不支持CALL_HELD也不支持CLCC但手機在Three way calling下支持CALL、F-不支持CALL_HELD也不支持CLCC而且手機Three way calling下不支持CALL。
對于支持CALL_HELD消息的AB類手機而言，我們可以通過CALL_HELD來判斷呼出結(jié)果，CALL_HELD=1表示對方接聽，CALL_HELD=0則表示對方拒接或未撥通；對于支持CLCC的CD類手機而言，如果手機在Three way calling下支持CALL，CALL=1則表示對方接聽，如果沒有CALL消息說明對方拒接或未撥通，這時需要在CALL_SETUP=0時讀取手機當(dāng)前的呼叫信息，然后根據(jù)該呼叫信息更新免提設(shè)備端的呼叫狀態(tài)；對于不支持CLCC和CALL_HELD的EF類手機而言，如果手機在Three way calling下支持CALL，CALL=1則表示對方接聽，否則在CALL_SETUP=0時默認將呼叫結(jié)果處理為對方拒接，即這個時候無法判斷呼出結(jié)果。
應(yīng)用上下文差異
藍牙是個對時間特性要求很嚴格的應(yīng)用，每種藍牙行為及其每個階段必須在相應(yīng)時間內(nèi)完成，否則可能造成失敗或者長時間無法響應(yīng)。應(yīng)用的上下文是指在某個藍牙行為完成后，下面將要進行什么樣的藍牙行為，它是由藍牙設(shè)備的應(yīng)用決定的，同類產(chǎn)品在應(yīng)用上的差異便會帶來應(yīng)用上下文上的差異，這樣便可能會帶來兼容性問題。比如在藍牙車載設(shè)備與藍牙手機互操作完成配對后，當(dāng)車載設(shè)備實現(xiàn)配對后的自動連接時，便由于手機在配對完成后的處理有所不同而遇到了兼容性問題。車載設(shè)備實現(xiàn)了配對后的自動連接功能，在配對完成后車載設(shè)備讀取外部設(shè)備的SDP進行服務(wù)查詢以判斷外部設(shè)備類型（包括免提、音頻流、免提+音頻流三種類型）然后自動連接其免提或音頻流服務(wù)，結(jié)果造成部分手機讀取SDP失敗、部分手機自動連接失敗、部分手機處于長時間無法響應(yīng)的狀態(tài)。
對于這種兼容性問題，需要對手機在不同應(yīng)用上下文的表現(xiàn)特性進行分析，并根據(jù)其差異進行分類。通過對手機在配對完成后的處理進行分析，有的手機配對完成后馬上自動連接，有的需要用戶確認再手動連接，有的會通過SDP讀取車載設(shè)備的服務(wù)列表然后針對車載設(shè)備提供的服務(wù)自動連接（車載設(shè)備提供免提服務(wù)、SPP服務(wù)、SyncML服務(wù)、流媒體音樂播放服務(wù)），而有的不會自動連接，這樣分類后，根據(jù)手機特性的不同設(shè)計實現(xiàn)配對后的自動連接如下：
藍牙車載設(shè)備在配對完成后的4秒內(nèi)無操作，配對后馬上自動連接的手機（如nokia 6500c）和大部分讀取SDP后自動連接的手機(如三星SGH-U608、SGH-E208)，可以迅速連接上車載設(shè)備。配對完成四秒后藍牙車載設(shè)備通過SDP判斷配對設(shè)備的類型（包括免提、音頻流、免提+音頻流三種類型），如果類型為免提+音頻流，則在連接免提成功后等待10秒再去連接音頻流，之所以10秒后再去連接音頻流是因為免提連接成功后，需要連接PBAP或SyncML或SPP去下載電話本，如果同時進行A2DP的連接去連接配對設(shè)備的流媒體服務(wù)，會造成鏈路丟失，免提連接及音頻流連接斷開。如果連接免提失敗，則不再連接其音頻流服務(wù)，因為有的手機如多普達D600的PDA手機，配對完成后讀取SDP然后自動連接，有時會造成免提連接不成功，如果去連接其音頻流，連接成功，但之后從車載設(shè)備端連接手機無法連接成功。斷開流媒體后，連接免提一直失敗，必須重新配對才行。
對于用戶確認手動連接的手機和部分讀取SDP然后自動連接車載設(shè)備的手機，在車載設(shè)備自動連接手機期間，可能會收到手機的連接請求，如果連接請求的手機與自動連接的手機為同一設(shè)備（藍牙地址相同），則接收該連接請求，否則會造成自動連接失敗。同時由于車載設(shè)備支持SPP的dev A，PDA手機的dev A可能會在配對后自動連接車載設(shè)備的SPP dev A，這時要拒絕該連接，如果不對該連接請求進行處理，會造成PDA手機處于長時間無法響應(yīng)的狀態(tài)。
引入?yún)f(xié)議帶來的兼容性
藍牙技術(shù)是個開放性的協(xié)議，它借鑒了很多成熟的已經(jīng)得到廣泛應(yīng)用的協(xié)議，比如Syncml，封裝在藍牙OBEX協(xié)議上可以實現(xiàn)個人信息的同步更新，比如vCard，它和PBAP、OPP協(xié)議結(jié)合，用來進行電話本條目和呼叫日志的封裝、下載和解析，這些協(xié)議本身便存在一定的兼容性問題，需要深入研究引入的協(xié)議，并盡量多得測試更多手機以盡量完善應(yīng)用程序。下面以vCard的解析為例來說明該兼容性問題的解決方法。
vCard是電子名片規(guī)范，定義了個人信息數(shù)據(jù)的存儲格式及訪問接口的規(guī)范，現(xiàn)在廣泛應(yīng)用的是v2.1版本和3.0版本，對于電話本條目和呼叫日志而言，關(guān)鍵信息為姓名、電話號碼及呼叫時間。含有多個電話號碼的電話本條目，我們將之定義為VCARD，其電話號碼包含家庭電話、工作電話、手機、車載電話四種屬性。
vCard樣例如下：
BEGIN:VCARD
VERSION:2.1
N;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE;:=9A=6C=5E=FA=8F=89
TEL;CELL:13475909642
TEL;WORK:053182605413
END:VCARD
以上的vCard樣例中，人名字段提取為“馬建輝”的UTF-8字符0x9A6C 0x5EFA 0x8F89，這部分的兼容性在于不同手機在封裝電話本條目的人名字段時所使用的字符集和編碼方式不一致，字符集有ASCII和UTF－8，編碼方式有8BIT、QUOTED-PRINTABLEPRINTABLE、BASE64這么幾種方式，需要對這幾種方式分別處理，比如以上vCard人名字段的處理需要把=9A=6C=5E=FA=8F=89轉(zhuǎn)換為0x9A6C 0x5EFA 0x8F89，處理代碼如下所示，temp_name數(shù)組為未處理的人名字符串，處理好的人名放在NAME數(shù)組中：
if(temp_name[i]=='=')
{
if((temp_name[i+1]>=0x41)&&(temp_name[i+1]<=0x46))
temp1=temp_name[i+1]-0x37;
else if((temp_name[i+1]>=0x30)&&(temp_name[i+1]<=0x39))
temp1=temp_name[i+1]-0x30;
if((temp_name[i+2]>=0x41)&&(temp_name[i+2]<=0x46))
temp2=temp_name[i+2]-0x37;
else if((temp_name[i+2]>=0x30)&&(temp_name[i+2]<=0x39))
temp2=temp_name[i+2]-0x30;
NAME[name_len]=(temp1<<4)+temp2;
name_len++;
i+=3;
}
另外還需要考慮一些特殊情況，如Sony Erricson 手機電話本條目的人名字段有時會把空格處理為0xE38080，所以如果提取出0xE38080，需要把該特殊字符以空格0x20代替，否則會處理為亂碼。
對于號碼字段的提取，關(guān)鍵字不僅是HOME、WORK、CELL、CAR，還要把PREF、VOICE作為可以被識別的關(guān)鍵字，而且有手機不帶關(guān)鍵字，把不帶關(guān)鍵字的處理為CELL即手機屬性即可。
呼叫時間，其字段以X-IRMC-CALL-DATETIME表示，其標準格式舉例如下：20080112T1212，年四個字節(jié)，月和日分別兩個字節(jié)，但對于部分手機，其月和日沒有嚴格遵循該規(guī)范，月+日字段共兩個字節(jié)或共三個字節(jié)，這就需要根據(jù)月和日的特性進行特殊處理了。處理代碼如下，月日字節(jié)數(shù)為temp_month_date_length，存放在temp_month_date數(shù)組中，
if(temp_month_date_length==2)
{
temp_month=temp_month_date[0]-0x30;
temp_date=temp_month_date[1]-0x30;
}
else if(temp_month_date_length==3)
{
if(temp_month_date[0]>0x31)//then the character must be month
{
//214-2 14
temp_month=temp_month_date[0]-0x30;
temp_date=(unsigned char)((temp_month_date[1]-0x30)*10+(temp_month_date[2]-0x30));
}
else if(temp_month_date[1]>0x32)
{
//130-1 30
temp_month=temp_month_date[0]-0x30;
temp_date=(unsigned char)((temp_month_date[1]-0x30)*10+(temp_month_date[2]-0x30));
}
else
{
//114 to month=11 date=4
temp_month=(unsigned char)((temp_month_date[0]-0x30)*10+(temp_month_date[1]-0x30));
temp_date=temp_month_date[2]-0x30;
if(temp_month>=11)
{
temp_month=0;
temp_date=0;
}
}
}
結(jié)語
兼容性是藍牙產(chǎn)品開發(fā)中的難點問題，本文分析了兼容性問題出現(xiàn)的原因，并結(jié)合具體實例分析其解決方法，有很好的借鑒意義。
下載文檔
