androidudp廣播包

⑴ android接收不到udp包嗎

1、有的手機不能直接接收UDP包，可能是手機廠商在定製Rom的時候把這個功能給關掉了。
2、在UDP通信中，android端發送UDP廣播包沒有問題。至於接收的話，有時候不能接收到包。

⑵ android wifi能進行udp的區域網廣播嗎，使用255.255.255.255這個地址~~~~

可以的，可以使用255.255.255.255進行廣播

⑶ Android手機只開啟Wifi，但是不連接任何一個路由器，能不能收到路由器轉發的UDP廣播數據包，如何現實

這個類似smartconfig吧，不連接的情況下進行配網，通過廣播的長度值來傳數據，要打開wifi模塊的混雜監聽模式才可以監聽某個頻段的數據，而且只有長度值可以改變，其他都不行

⑷ android 如何定時發udp

定時執行任務可以考慮使用AlarmManager配合BroadcastReceiver實現
AlarmManager定時發出intent，BroadCastReceiver收到這個intent後進行發送UDP的操作

⑸ Android 手機上能通過DatagramSocket收到PC端的UDP廣播嗎

在PC端直接用tcp調試助手發送數據，我另一台電腦能收到的，但是android的卻是有時可以收到有時收不到，平均幾十次收到10次左右，丟包不可能這么嚴重吧。，android的代碼如下，
ds = new DatagramSocket(1234, InetAddress.getByName(「192.168.1.3」));
dp = new DatagramPacket(content, content.length);
ds.receive(dp);
如果我在pc端發送綁定了IP的UDP數據包，android可以收到數據，但是PC端發送255的廣播UDP，android就收不到了。。查了一些資料，說是要加入許可權，加入以下的代碼，但實測發現效果一樣。

WifiManager manager = (WifiManager) this.getSystemService(Context.WIFI_SERVICE); WifiManager.MulticastLock lock= manager.createMulticastLock("localWifi");

⑹ android藍牙BLE（三） —— 廣播

​ 在藍牙開發中，有些情況是不需要連接的，只要外設廣播自己的數據即可，例如蘋果的 ibeacon 。自 Android 5.0 更新藍牙API後，手機可以作為外設廣播數據。

廣播包有兩種：

其中 廣播包是每個外設都必須廣播的，而響應包是可選的 。每個廣播包的長度必須是 31個位元組 ，如果不到 31個位元組 ，則剩下的全用 0 填充 補全，這部分的數據是無效的

廣播包中包含若干個廣播數據單元，廣播數據單元也稱為 AD Structure 。

廣播數據單元 = 長度值Length + AD type + AD Data。

長度值 Length 只佔 一個位元組 ，並且位於廣播數據單元的 第一個位元組 。

概念的東西有些抽象，先看看下面的廣播報文：

​ 0x代表這串字元串是十六進制的字元串。 兩位十六進制數代表一個位元組 。因為兩個字元組成的十六進制字元串最大為 FF ，即255，而java中byte類型的取值范圍是-128到127，剛好可以表示一個255的大小。所以兩個十六進制的字元串表示一個位元組。

​ 繼續查看報文內容，開始讀取第一個廣播數據單元。讀取 第一個 位元組: 0x07 ,轉換為十進制就是7，即表示後面的7個位元組是這個廣播數據單元的數據內容。超過這7個位元組的數據內容後，表示是一個新的廣播數據單元。

​ 而第二個廣播數據單元，第一個位元組的值是 0x16 ,轉換為十進制就是22，表示後面22個位元組為第二個廣播數據單元。

​ 在廣播數據單元的 數據部分 中， 第一個位元組 代表 數據類型 （AD type），決定數據部分表示的是什麼數據。（即廣播數據單元第二個位元組為AD type）

AD Type 的類型如下：

​ 這bit 1~7分別代表著發送該廣播的藍牙晶元的物理連接狀態。當bit的值為1時，表示支持該功能。
例：

藍牙廣播的數據格式大致講了一下，有助於下面的廣播操作的理解。

先看看廣播設置（ AdvertiseSettings ）如何定義：

（1）、通過 AdvertiseSettings.Builder#setAdvertiseMode() 設置廣播模式。其中有3種模式：

（2）、通過 AdvertiseSettings.Builder#setAdvertiseMode() 設置廣播發射功率。共有4種功率模式：

（3）、通過 AdvertiseSettings.Builder#setTimeout() 設置持續廣播的時間，單位為毫秒。最多180000毫秒。當值為0則無時間限制，持續廣播，除非調用 BluetoothLeAdvertiser#stopAdvertising() 停止廣播。

（4）、通過 AdvertiseSettings.Builder#setConnectable() 設置該廣播是否可以連接的。

之前說過，外設必須廣播廣播包，掃描包是可選。但添加掃描包也意味著廣播更多得數據，即可廣播62個位元組。

可見無論是廣播包還是掃描包，其廣播的內容都是用 AdvertiseData 類封裝的。

（1）、 AdvertiseData.Builder#setIncludeDeviceName() 方法，可以設置廣播包中是否包含藍牙的名稱。

（2）、 AdvertiseData.Builder#setIncludeTxPowerLevel() 方法，可以設置廣播包中是否包含藍牙的發射功率。

（3）、 AdvertiseData.Builder#addService UUID (Parcel UUID ) 方法，可以設置特定的 UUID 在廣播包中。

（4）、 AdvertiseData.Builder#addServiceData(Parcel UUID ，byte[]) 方法，可以設置特定的 UUID 和其數據在廣播包中。

（5）、 AdvertiseData.Builder#addManufacturerData(int，byte[]) 方法，可以設置特定廠商Id和其數據在廣播包中。

​ 從 AdvertiseData.Builder 的設置中可以看出，如果一個外設需要在不連接的情況下對外廣播數據，其數據可以存儲在 UUID 對應的數據中，也可以存儲在廠商數據中。但由於廠商ID是需要由Bluetooth SIG進行分配的，廠商間一般都將數據設置在廠商數據。

另外可以通過 BluetoothAdapter#setName() 設置廣播的名稱

先看一個例子，我們分別在 廣播包 和 掃描包 中設置 AdvertiseData.Builder 的 每一種廣播報文參數 ，得到一下報文內容：

(1)、Type = 0x01 表示設備LE物理連接。

(2)、Type = 0x09 表示設備的全名

(3)、Type = 0x03 表示完整的16bit UUID 。其值為0xFFF7。

(4)、Type = 0xFF 表示廠商數據。前兩個位元組表示廠商ID,即廠商ID為0x11。後面的為廠商數據，具體由用戶自行定義。

(5)、Type = 0x16 表示16 bit UUID 的數據，所以前兩個位元組為 UUID ,即 UUID 為0xF117，後續為 UUID 對應的數據，具體由用戶自行定義。

最後繼承 AdvertiseCallback 自定義廣播回調。

初始化完畢上面的對象後，就可以進行廣播：

​ 廣播主要是通過 BluetoothLeAdvertiser#startAdvertising() 方法實現，但在之前需要先獲取 BluetoothLeAdvertiser 對象。

BluetoothLeAdvertiser 對象存在兩個情況獲取為Null:

所以在調用 BluetoothAdapter#getBluetoothLeAdvertiser() 前，需要先調用判斷藍牙已開啟，並判斷在 BluetoothAdapter 中獲取的 BluetoothLeAdvertiser 是否為空（測試過某些華為手機 mBluetoothAdapter.() 為 false , 但是能發送ble廣播）。

​ 與廣播成對出現就是 BluetoothLeAdvertiser.stopAdvertising() 停止廣播了，傳入開啟廣播時傳遞的廣播回調對象，即可關閉廣播：

​ 雖然通過廣播告知外邊自身擁有這些Service,但手機自身並沒有初始化Gattd的Service。導致外部的中心設備連接手機後，並不能找到對應的 GATT Service 和 獲取對應的數據。

Service類型有兩個級別：

創建 BluetoothGattService 時，傳入兩個參數： UUID 和Service類型：

​ 我們都知道Gatt中， Service 的下一級是 Characteristic ， Characteristic 是最小的通信單元，通過對 Characteristic 進行讀寫操作來進行通信。

​ 特徵屬性表示該 BluetoothGattCharacteristic 擁有什麼功能，即能對 BluetoothGattCharacteristic 進行什麼操作。其中主要有3種：

許可權屬性用於配置該特徵值所具有的功能。主要兩種：

Characteristic 下還有 Descriptor ，初始化 BluetoothGattDescriptor 時傳入： Descriptor UUID 和 許可權屬性

為 Service 添加 Characteristic ，為 Characteristic 添加 Descriptor ：

​ 通過藍牙管理器 mBluetoothManager 獲取 Gatt Server ，用來添加 Gatt Service 。添加完 Gatt Service 後，外部中心設備連接手機時，將能獲取到對應的 GATT Service 和 獲取對應的數據

​ 定義 Gatt Server 回調。當中心設備連接該手機外設、修改特徵值、讀取特徵值等情況時，會得到相應情況的回調。

最後開啟廣播後，用nRF連接後看到的特徵值信息如下圖所示：（加多了一個只能都的特徵值）

android藍牙BLE（一） —— 掃描

android藍牙BLE（二） —— 通信

android藍牙BLE（三） —— 廣播

android藍牙BLE（四） —— 實戰

⑺ 22 AndroidBroadcast廣播機制

廣播(Broadcast)機制用於進程/線程間通信，廣播分為廣播發送和廣播接收兩個過程，其中廣播接收者BroadcastReceiver便是Android四大組件之一。

BroadcastReceiver分為兩類：

從廣播發送方式可分為三類：

廣播在系統中以BroadcastRecord對象來記錄, 該對象有幾個時間相關的成員變數.

廣播注冊，對於應用開發來說，往往是在Activity/Service中調用 registerReceiver() 方法，而Activity或Service都間接繼承於Context抽象類，真正幹活是交給ContextImpl類。另外調用getOuterContext()可獲取最外層的調用者Activity或Service。

[ContextImpl.java]

其中broadcastPermission擁有廣播的許可權控制，scheler用於指定接收到廣播時onRecive執行線程，當scheler=null則默認代表在主線程中執行，這也是最常見的用法

[ContextImpl.java]

ActivityManagerNative.getDefault()返回的是ActivityManagerProxy對象，簡稱AMP.
該方法中參數有mMainThread.getApplicationThread()返回的是ApplicationThread，這是Binder的Bn端，用於system_server進程與該進程的通信。

[-> LoadedApk.java]

不妨令 以BroadcastReceiver(廣播接收者)為key，LoadedApk.ReceiverDispatcher(分發者)為value的ArrayMap 記為 A 。此處 mReceivers 是一個以 Context 為key，以 A 為value的ArrayMap。對於ReceiverDispatcher(廣播分發者)，當不存在時則創建一個。

此處mActivityThread便是前面傳遞過來的當前主線程的Handler.

ReceiverDispatcher(廣播分發者)有一個內部類 InnerReceiver ，該類繼承於 IIntentReceiver.Stub 。顯然，這是一個Binder服務端，廣播分發者通過rd.getIIntentReceiver()可獲取該Binder服務端對象 InnerReceiver ，用於Binder IPC通信。

[-> ActivityManagerNative.java]

這里有兩個Binder服務端對象 caller 和 receiver ，都代表執行注冊廣播動作所在的進程. AMP通過Binder驅動將這些信息發送給system_server進程中的AMS對象，接下來進入AMS.registerReceiver。

[-> ActivityManagerService.java]

其中 mRegisteredReceivers 記錄著所有已注冊的廣播，以receiver IBinder為key, ReceiverList為value為HashMap。

在BroadcastQueue中有兩個廣播隊列mParallelBroadcasts,mOrderedBroadcasts，數據類型都為ArrayList<broadcastrecord style="box-sizing: border-box;">：</broadcastrecord>

mLruProcesses數據類型為 ArrayList<ProcessRecord> ，而ProcessRecord對象有一個IApplicationThread欄位，根據該欄位查找出滿足條件的ProcessRecord對象。

該方法用於匹配發起的Intent數據是否匹配成功，匹配項共有4項action, type, data, category，任何一項匹配不成功都會失敗。

broadcastQueueForIntent(Intent intent)通過判斷intent.getFlags()是否包含FLAG_RECEIVER_FOREGROUND 來決定是前台或後台廣播，進而返回相應的廣播隊列mFgBroadcastQueue或者mBgBroadcastQueue。

注冊廣播：

另外，當注冊的是Sticky廣播：

廣播注冊完, 另一個操作便是在廣播發送過程.

發送廣播是在Activity或Service中調用 sendBroadcast() 方法，而Activity或Service都間接繼承於Context抽象類，真正幹活是交給ContextImpl類。

[ContextImpl.java]

[-> ActivityManagerNative.java]

[-> ActivityManagerService.java]

broadcastIntent()方法有兩個布爾參數serialized和sticky來共同決定是普通廣播，有序廣播，還是Sticky廣播，參數如下：

broadcastIntentLocked方法比較長，這里劃分為8個部分來分別說明。

這個過程最重要的工作是：

BroadcastReceiver還有其他flag，位於Intent.java常量:

主要功能：

這個過主要處於系統相關的10類廣播,這里不就展開講解了.

這個過程主要是將sticky廣播增加到list，並放入mStickyBroadcasts裡面。

其他說明：

AMS.collectReceiverComponents ：

廣播隊列中有一個成員變數 mParallelBroadcasts ，類型為ArrayList<broadcastrecord style="box-sizing: border-box;">，記錄著所有的並行廣播。</broadcastrecord>

動態注冊的registeredReceivers，全部合並都receivers，再統一按串列方式處理。

廣播隊列中有一個成員變數 mOrderedBroadcasts ，類型為ArrayList<broadcastrecord style="box-sizing: border-box;">，記錄著所有的有序廣播。</broadcastrecord>

發送廣播過程:

處理方式：

可見不管哪種廣播方式，都是通過broadcastQueueForIntent()來根據intent的flag來判斷前台隊列或者後台隊列，然後再調用對應廣播隊列的scheleBroadcastsLocked方法來處理廣播；

在發送廣播過程中會執行 scheleBroadcastsLocked 方法來處理相關的廣播

[-> BroadcastQueue.java]

在BroadcastQueue對象創建時，mHandler=new BroadcastHandler(handler.getLooper());那麼此處交由mHandler的handleMessage來處理：

由此可見BroadcastHandler採用的是」ActivityManager」線程的Looper

[-> BroadcastQueue.java]

此處mService為AMS，整個流程還是比較長的，全程持有AMS鎖，所以廣播效率低的情況下，直接會嚴重影響這個手機的性能與流暢度，這里應該考慮細化同步鎖的粒度。