# Android基于Cling开发DLNA应用

## DLNA

DLNA,Digital Living Network Alliance的简称,即数字生活网络联盟。其由消费性电子、移动电话以及电脑厂商组成。目标在于创建一套可以使得各厂商的产品互相连接,互相适应的工业标准,从而为消费者实现数字化生活。

更多资料:

1. About DLNA
2. 维基百科
3. 百度百科

## Cling

UPnP/DLNA library for Java and Android。

GitHub最多关注,当前仍在维护,许可协议为LGPL或CDDL。

用户手册:Cling on Android

以下为中文译文:

 
    
  1. ## 5. Android上的Cling 
  2. Cling Core为Android应用提供了UPnP栈。由于如今大部分Android系统都是小型手持设备,所以通常你需要写控制端应用。然而你也可以写Android上的UPnP服务应用,其所有特性Cling Core都支持。 
  3.  
  4. ``` 
  5. Android模拟器上的Cling 
  6. 在写此时,Android模拟器还不支持接收UDP组播。不过,可以发送UDP组播。你能够发送一个组播UPnP搜寻,并接收UDP单播回应,继而发现正运行的设备。你发现不了在搜寻后新开启的设备,并且在设备关闭时也收不到消息。另外,其他在你网络的控制端应用,则不能发现你本地的Android设备或服务。在你测试应用时,所有这些情况都会使你感到困惑,所以除非你真得理解哪些有作用、哪些没有,不然你应当使用一个真正的设备。 
  7. 这章阐述了你如何整合Cling到你的Android应用,使其成为一个共享的部件。 
  8. ``` 
  9.  
  10. ### 5.1. 配置应用服务 
  11. 你可以在Android应用主activity中实例化Cling UpnpService。另一方面,如果你好些activities都要要求访问UPnP栈,那么最好采用后台服务,android.app.Service。之后,任何想要访问UPnP栈的activity,都能够在需要时绑定或解绑该服务。 
  12.  
  13. 该服务组件的接口是org.teleal.cling.android.AndroidUpnpService: 
  14.  
  15. ``` 
  16. public interface AndroidUpnpService { 
  17.     public UpnpService get(); 
  18.     public UpnpServiceConfiguration getConfiguration(); 
  19.     public Registry getRegistry(); 
  20.     public ControlPoint getControlPoint(); 
  21. ``` 
  22.  
  23. activity通常访问已知UPnP设备的注册表,或者通过ControlPoint查询和控制UPnP设备。 
  24. 你必须在AndroidManifest.xml内配置内建的服务实现: 
  25.  
  26. ``` 
  27.  
  28.  
  29.     name="android.permission.INTERNET"/> 
  30.     name="android.permission.ACCESS_WIFI_STATE"/> 
  31.     name="android.permission.CHANGE_WIFI_MULTICAST_STATE"/> 
  32.     name="android.permission.ACCESS_NETWORK_STATE"/> 
  33.  
  34.      
  35.  
  36.          
  37.             ... 
  38.          
  39.  
  40.         name="org.teleal.cling.android.AndroidUpnpServiceImpl"/> 
  41.  
  42.      
  43.  
  44.  
  45. ``` 
  46.  
  47. 此Cling UPnP服务要求设备WiFi接口的访问权限,事实上其也只将会绑定网络接口。 
  48. 此服务将会自动检测WiFi接口的关闭,并优雅地处理这种情形:任何客户端操作都会导致"no response from server"状态,而你的代码必须预料并处理该状态。 
  49.  
  50. 当服务组件创建或销毁时,会相应开启和关闭UPnP系统。这依赖于在你的activities里是如何访问此组件的。 
  51.  
  52. ### 5.2 activity如何访问服务 
  53. service的生命周期在Android中很好的被定义了。如果service还没启动的话,第一个绑定服务的activity将会启动它。当不再有activity绑定到service上时,操作系统将会销毁此service。 
  54.  
  55. 让我们写一个简单的UPnP浏览activity。它用于将所有你网络内的设备显示在一个列表内,并有一个菜单选项来触发搜寻。activity连接UPnP服务之后,会一直监听注册表内设备的增加和删除,所以显示的设备列表会实时更新。 
  56.  
  57. 以下是activity类的骨架: 
  58.  
  59. ``` 
  60. import android.app.ListActivity; 
  61. import android.content.ComponentName; 
  62. import android.content.Context; 
  63. import android.content.Intent; 
  64. import android.content.ServiceConnection; 
  65. import android.os.Bundle; 
  66. import android.os.IBinder; 
  67. import android.view.Menu; 
  68. import android.view.MenuItem; 
  69. import android.widget.ArrayAdapter; 
  70. import android.widget.Toast; 
  71. import org.teleal.cling.android.AndroidUpnpService; 
  72. import org.teleal.cling.android.AndroidUpnpServiceImpl; 
  73. import org.teleal.cling.model.meta.Device; 
  74. import org.teleal.cling.model.meta.LocalDevice; 
  75. import org.teleal.cling.model.meta.RemoteDevice; 
  76. import org.teleal.cling.registry.DefaultRegistryListener; 
  77. import org.teleal.cling.registry.Registry; 
  78.  
  79. public class UpnpBrowser extends ListActivity { 
  80.  
  81.     private ArrayAdapter listAdapter; 
  82.  
  83.     private AndroidUpnpService upnpService; 
  84.  
  85.     private ServiceConnection serviceConnection = ... 
  86.  
  87.     private RegistryListener registryListener = new BrowseRegistryListener(); 
  88.  
  89.     @Override 
  90.     public void onCreate(Bundle savedInstanceState) { 
  91.         super.onCreate(savedInstanceState); 
  92.  
  93.         listAdapter = 
  94.             new ArrayAdapter( 
  95.                 this, 
  96.                 android.R.layout.simple_list_item_1 
  97.             ); 
  98.         setListAdapter(listAdapter); 
  99.  
  100.         getApplicationContext().bindService( 
  101.             new Intent(this, AndroidUpnpServiceImpl.class), 
  102.             serviceConnection, 
  103.             Context.BIND_AUTO_CREATE 
  104.         ); 
  105.     } 
  106.  
  107.     @Override 
  108.     protected void onDestroy() { 
  109.         super.onDestroy(); 
  110.         if (upnpService != null) { 
  111.             upnpService.getRegistry().removeListener(registryListener); 
  112.         } 
  113.         getApplicationContext().unbindService(serviceConnection); 
  114.     } 
  115.  
  116.     ... 
  117.  
  118. ``` 
  119.  
  120. 我们采用Android运行时默认提供的布局和ListActivity父类。注意这个类可以是你应用的主activity,或者进一步上升进任务的堆栈。listAdapter黏合了Cling Registry上设备的增加移除事件与展示在用户界面的列表项目。 
  121.  
  122. 当没有后台服务绑定到该activity时,upnpService变量为null。绑定和解绑发生在onCreate()和onDestroy()回调,所以activity绑定服务和它的生存周期一样长。 
  123.  
  124. ``` 
  125. 暂停后台的UPnP服务 
  126. 当一个activity不再活动时(停止或暂停状态),它仍会绑定着UPnP服务。UPnP服务将会持续运行,即使应用不再可见。由于UPnP服务的注册表一定会定期维护发现的设备、刷新本地设备的通告、删除过期的GENA事件订阅等,将会消耗你设备的CPU和电量。当activity onPause()或onStop()方法被调用时,你可以调用Registry#pause()来通知UPnP服务不再维护注册表。之后,你可以通过Registry#resume()来恢复后台服务,或同时用Registry#isPaused()检查状态。请阅读这些方法的Javadoc了解详细信息,以及暂停注册表维护对于设备、服务和GENA订阅的意义。 
  127. ``` 
  128.  
  129. 以下是使用ServiceConnection处理绑定和解绑服务: 
  130.  
  131. ``` 
  132. private ServiceConnection serviceConnection = new ServiceConnection() { 
  133.  
  134.     public void onServiceConnected(ComponentName className, IBinder service) { 
  135.         upnpService = (AndroidUpnpService) service; 
  136.  
  137.         // Refresh the list with all known devices 
  138.         listAdapter.clear(); 
  139.         for (Device device : upnpService.getRegistry().getDevices()) { 
  140.             registryListener.deviceAdded(device); 
  141.         } 
  142.  
  143.         // Getting ready for future device advertisements 
  144.         upnpService.getRegistry().addListener(registryListener); 
  145.  
  146.         // Search asynchronously for all devices 
  147.         upnpService.getControlPoint().search(); 
  148.     } 
  149.  
  150.     public void onServiceDisconnected(ComponentName className) { 
  151.         upnpService = null
  152.     } 
  153. }; 
  154. ``` 
  155.  
  156. 首先,所有已知的UPnP设备能够被查询和显示(如果UPnP服务刚开启且到到目前还没有设备通告它的存在)。 
  157.  
  158. 然后,给UPnP服务的注册表增加一个监听者。该监听者将会处理在你网络上发现的设备的增加和移除,并在更新在用户界面列表内显示的项目。当activity销毁时,BrowseRegistryListener会被移除。 
  159.  
  160. 最后,通过发送一个搜寻消息给所有UPnP设备,你会开启异步搜索,此时这些设备将通告它们的存在。注意这个搜寻消息不是每次连接服务都需要的。这只需一次,在当主activity和应用启动时,其会将已知设备写入注册表。 
  161.  
  162. 以下是BrowseRegistryListener,他的任务就是更新列表项的显示: 
  163.  
  164. ``` 
  165. class BrowseRegistryListener extends DefaultRegistryListener { 
  166.  
  167.     @Override 
  168.     public void remoteDeviceDiscoveryStarted(Registry registry, RemoteDevice device) { 
  169.         deviceAdded(device); 
  170.     } 
  171.  
  172.     @Override 
  173.     public void remoteDeviceDiscoveryFailed(Registry registry, final RemoteDevice device, final Exception ex) { 
  174.         runOnUiThread(new Runnable() { 
  175.             public void run() { 
  176.                 Toast.makeText( 
  177.                         BrowseActivity.this, 
  178.                         "Discovery failed of '" + device.getDisplayString() + "': " + 
  179.                                 (ex != null ? ex.toString() : "Couldn't retrieve device/service descriptors"), 
  180.                         Toast.LENGTH_LONG 
  181.                 ).show(); 
  182.             } 
  183.         }); 
  184.         deviceRemoved(device); 
  185.     } 
  186.  
  187.     @Override 
  188.     public void remoteDeviceAdded(Registry registry, RemoteDevice device) { 
  189.         deviceAdded(device); 
  190.     } 
  191.  
  192.     @Override 
  193.     public void remoteDeviceRemoved(Registry registry, RemoteDevice device) { 
  194.         deviceRemoved(device); 
  195.     } 
  196.  
  197.     @Override 
  198.     public void localDeviceAdded(Registry registry, LocalDevice device) { 
  199.         deviceAdded(device); 
  200.     } 
  201.  
  202.     @Override 
  203.     public void localDeviceRemoved(Registry registry, LocalDevice device) { 
  204.         deviceRemoved(device); 
  205.     } 
  206.  
  207.     public void deviceAdded(final Device device) { 
  208.         runOnUiThread(new Runnable() { 
  209.             public void run() { 
  210.                 DeviceDisplay d = new DeviceDisplay(device); 
  211.                 int position = listAdapter.getPosition(d); 
  212.                 if (position >= 0) { 
  213.                     // Device already in the list, re-set new value at same position 
  214.                     listAdapter.remove(d); 
  215.                     listAdapter.insert(d, position); 
  216.                 } else { 
  217.                     listAdapter.add(d); 
  218.                 } 
  219.             } 
  220.         }); 
  221.     } 
  222.  
  223.     public void deviceRemoved(final Device device) { 
  224.         runOnUiThread(new Runnable() { 
  225.             public void run() { 
  226.                 listAdapter.remove(new DeviceDisplay(device)); 
  227.             } 
  228.         }); 
  229.     } 
  230. ``` 
  231.  
  232. 鉴于性能的原因,当发现设备时,我们会直到一个完整的hydrated(所有设备被检索和验证)设备元数据模型可用时才执行等待。我们响应尽可能得快,同时只当remoteDeviceAdded()方法被调用时才去等待。甚至当搜索仍在运行时,我们仍旧显示所有设备。在台式电脑上你通常不需要关心这个,不过,Android手持设备效率慢,并且UPnP使用好些臃肿的XML描述符来交换关于设备和服务的元数据。有时,在设备和它的服务完全可用前,这可能会花费数秒钟。而remoteDeviceDiscoveryStarted()和remoteDeviceDiscoveryFailed()方法在搜索处理时会尽快被调用。顺便说一句,如果设备有相同的UDN就表示相等的(a.equal(b)),但它们可能不会完全一致(a==b)。 
  233.  
  234. 注意注册表将会在分开的线程中调用监听者方法。你必须在UI线程中更新显示列表数据。 
  235.  
  236. activity中以下两个方法增加了用来搜寻的菜单,如此用户才能手动的刷新列表: 
  237.  
  238. ``` 
  239. @Override 
  240. public boolean onCreateOptionsMenu(Menu menu) { 
  241.     menu.add(0, 0, 0, R.string.search_lan) 
  242.         .setIcon(android.R.drawable.ic_menu_search); 
  243.     return true
  244.  
  245. @Override 
  246. public boolean onOptionsItemSelected(MenuItem item) { 
  247.     if (item.getItemId() == 0 && upnpService != null) { 
  248.         upnpService.getRegistry().removeAllRemoteDevices(); 
  249.         upnpService.getControlPoint().search(); 
  250.     } 
  251.     return false
  252. ``` 
  253.  
  254. 最后,DeviceDisplay类是一个非常简单的JavaBean,只提供一个toString()方法来呈现列表信息。通过修改此方法,你能够显示任何关于UPnP设备的信息: 
  255.  
  256. ``` 
  257. class DeviceDisplay { 
  258.     Device device; 
  259.  
  260.     public DeviceDisplay(Device device) { 
  261.         this.device = device; 
  262.     } 
  263.  
  264.     public Device getDevice() { 
  265.         return device; 
  266.     } 
  267.  
  268.     @Override 
  269.     public boolean equals(Object o) { 
  270.         if (this == o) return true
  271.         if (o == null || getClass() != o.getClass()) return false
  272.         DeviceDisplay that = (DeviceDisplay) o; 
  273.         return device.equals(that.device); 
  274.     } 
  275.  
  276.     @Override 
  277.     public int hashCode() { 
  278.         return device.hashCode(); 
  279.     } 
  280.  
  281.     @Override 
  282.     public String toString() { 
  283.         // Display a little star while the device is being loaded 
  284.         return device.isFullyHydrated() ? device.getDisplayString() : device.getDisplayString() + " *"
  285.     } 
  286. ``` 
  287.  
  288. 还有我们必须覆盖相等操作,这样我们才可以用DeviceDisplay实例作为便捷的处理,从列表中手动地移除和增加设备。 
  289.  
  290. ### 5.3. 优化服务行为 
  291. UPnP服务运行时会消耗内存和CPU。尽管通常在一个正常的机器上没有什么问题,但在Android手持设备上就可能会有了。如果你禁用Cling UPnP服务的某些功能,或者设置暂停且在合适时恢复它,你可以留有更多的内存和电量。 
  292.  
  293. #### 5.3.1. 调整注册表维护 
  294. 当服务运行时,后台有好些东西在执行。首先,有一个服务的注册表和其维护线程。如果你写一个控制端,后台注册表维护者将会定期从远程服务更新你对外的GENA订阅。当没有通知断开网络时,它也会到期并移除任何远程服务。如果你正提供服务,你的设备通告将被注册表维护者刷新,并在GENA订阅没及时更新时移除它。注册表维护者为了有效得防止UPnP网络上的过时状态,所以所有参与者会实时更新其他参与者的视图等等。 
  295.  
  296. 默认情况下,注册表维护者会每秒运行并检查是否有事要做(当然,大多数情况下没事做)。然而默认的Android配置有5秒的间隔休眠,所以这已经花费了更少的后台CPU占用时间 — 不过你的应用可能会暴露稍微过时的信息。在UpnpServiceConfiguration你可以通过覆盖getRegistryMaintenanceIntervalMillis()进一步的调整设置。在Android上,你必须子类化服务实现来提供一个新的配置。 
  297.  
  298. ``` 
  299. public class MyUpnpService extends AndroidUpnpServiceImpl { 
  300.  
  301.     @Override 
  302.     protected AndroidUpnpServiceConfiguration createConfiguration(WifiManager wifiManager) { 
  303.         return new AndroidUpnpServiceConfiguration(wifiManager) { 
  304.  
  305.             @Override 
  306.             public int getRegistryMaintenanceIntervalMillis() { 
  307.                 return 7000; 
  308.             } 
  309.  
  310.         }; 
  311.     } 
  312. ``` 
  313.  
  314. 此时不要忘了在AndroidManifest.xml内配置MyUpnpService,而不是原先的实现。当在你的activities里绑定服务时,也必须使用该类型。 
  315.  
  316. #### 5.3.2. 暂停和恢复注册表维护 
  317. 另外一个更有效同时也不是很复杂的优化是,每当你的activites不再需要UPnP服务时,暂停和恢复注册表。这通常发生在当activity不在前台(暂停),甚至不再显示(停止)时。默认情况下,activity状态改变对UPnP服务没有影响,除非你在activities生命周期的回调内绑定和解绑服务。 
  318.  
  319. 除了绑定和解绑服务,你也可以在activity onPause()或onStop()方法被调用时,通过调用Registry#pause()来暂停注册表。之后,你可以通过Registry#resume()来恢复后台服务,或同时用Registry#isPaused()检查状态。 
  320.  
  321. 请阅读这些方法的Javadoc了解详细信息,以及暂停注册表维护对于设备、服务和GENA订阅的意义。根据你的应用要做什么,否则这种小的优化可能不值得处理这些效果。另一方面,你的应用应当能够处理失败的GENA订阅续期,或者消失的远程设备。 
  322.  
  323. #### 5.3.3. 配置搜索 
  324. 最有效的优化是UPnP设备有选择性的搜索。尽管UPnP服务的网络传输层在后台会保持运行(线程正等待且socket被绑定),这个特性允许你有选择且快速的丢弃搜索信息。 
  325.  
  326. 举例来说,如果你正在写一个控制端,且不通告你想要控制的服务(对其他设备没兴趣),那么你可以丢弃所有接收的搜索信息。另一方面,如果你只提供设备和服务,所有搜索信息(除了你自身服务的搜索信息)可能都可以被丢弃,你对其他远程设备和其服务一点都不会有兴趣。 
  327.  
  328. 一旦UDP数据包内容可用,该搜索信息就会被Cling选择并偷偷的丢弃,所以不需要进一步得解析和处理,同时CPU时间和内存消耗显著得减少,即使当你在Android手持设备上后台持续运行UPnP服务。 
  329.  
  330. 为了配置你的控制端应用支持哪些服务,需要覆盖前面章节展示的服务接口并提供一组ServiceType实例: 
  331.  
  332. ``` 
  333. public class MyUpnpService extends AndroidUpnpServiceImpl { 
  334.  
  335.     @Override 
  336.     protected AndroidUpnpServiceConfiguration createConfiguration(WifiManager wifiManager) { 
  337.         return new AndroidUpnpServiceConfiguration(wifiManager) { 
  338.  
  339.             @Override 
  340.             public ServiceType[] getExclusiveServiceTypes() { 
  341.                 return new ServiceType[] { 
  342.                         new UDAServiceType("SwitchPower"
  343.                 }; 
  344.             } 
  345.  
  346.         }; 
  347.     } 
  348. ``` 
  349.  
  350. 这个配置将会忽略所有不通告chemas-upnp-org:SwitchPower:1的任何通告。这是我们控制端要处理的,不需要其他任何东西了。如果你返回一个空的数组(默认行为),所有服务和设备将会发现以及没有通告会被丢弃。 
  351.  
  352. 如果你正在写一个控制端应用而不是服务应用,你可以让getExclusiveServiceTypes()方法返回null。这将会完全禁用搜索,此时所有设备和服务的通告一接收就会被丢弃。