智能終端升級需求解決思路_第1頁
智能終端升級需求解決思路_第2頁
智能終端升級需求解決思路_第3頁
智能終端升級需求解決思路_第4頁
智能終端升級需求解決思路_第5頁
已閱讀5頁,還剩30頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

1、智能終端升級需求解決思路互動電視技術(shù)部2022年10月3日版本記錄版本修訂人修訂內(nèi)容修訂時間評審人 評審意見0.1祝麗娟初稿陸忠強,楊懿通過,下一步征詢廠家技術(shù)建議書0.2祝麗娟增加日志模塊目錄第一部分:需求說明第二部分:技術(shù)原理分析第三部分:需求分析與解決方案第四部分:問題、難點與風險第五部分:方案總結(jié)需求說明假設與前提:基于安卓系統(tǒng)或經(jīng)改造的安卓系統(tǒng)(如阿里OS)的智能終端DVB+OTT和IP互動OTT產(chǎn)品C/S模式,C/S+B/S模式下APK升級需求概述:終端升級類:對終端升級的要求,包括升級方式、升級通道、升級包內(nèi)容、升級模式、升級校驗等運營管理類需求:對運營管理的要求,包括升級規(guī)模(

2、如系統(tǒng)并發(fā)支持的升級項目)、升級區(qū)域管理、升級時間段管理、按匹配規(guī)則(如TVID、軟件版本、硬件版本等)升級、強制升級管理等需求詳情:參考李新梳理的需求材料第一部分:需求說明第二部分:技術(shù)原理分析第三部分:需求分析與解決方案第四部分:問題、難點與風險第五部分:方案總結(jié)目錄安卓體系結(jié)構(gòu)圖 APK升級 ROM升級 應用市場升級目錄APK升級原理AndroidManifest.xml 是每個安卓程序中必須的文件。它位于整個項目的根目錄,描述了package中暴露的組件(activities, services, 等等),他們各自的實現(xiàn)類,各種能被處理的數(shù)據(jù)和啟動位置在AndroidManifest.

3、xml里定義了每個安卓APK的版本標識android:versionCode和android:versionName兩個字段分別表示版本代碼,版本名稱。versionCode是整型數(shù)字,versionName是字符串。由于version是給用戶看的,不太容易比較大小,升級檢查時,一般以檢查versionCode為主,方便比較出版本的前后大小APK升級原理一般APK在開發(fā)時會實現(xiàn)更新管理,主要實現(xiàn)的功能包括:服務器端最新版本獲取,本地版本獲取,服務器端版本與本地版本比較,下載管理,安裝管理,交互UI 等APK升級也支持增量升級。常見于手機應用場景,用于節(jié)省流量。服務器端將舊版APK和新版APK做

4、差分,可使用bsdiff,Courgette等方法實現(xiàn),得到更新部分的補丁。用戶下載差分包。用戶在終端需要將舊版APK和差分包進行合成。該方法存在兩個明顯缺點:1.服務器端需對每個發(fā)布版本與最新版做差分;2.用戶端升級成功的前提是用戶端的版本與服務端用于差分的版本一致,如發(fā)生內(nèi)置APK版本無法獲取、版本一致但內(nèi)容有修改(如破解)等情況,則會失敗 APK升級 ROM升級 應用市場升級目錄標準安卓啟動模式Recovery模式工作原理Recovery的工作需要整個軟件平臺的配合,從通信架構(gòu)上來看,主要有三個部分:MainSystem:正常啟動模式(BCB中無命令),是用boot.img啟動的系統(tǒng),A

5、ndroid的正常工作模式。更新時,在這種模式中上層操作就是使用OTA或從SD卡中升級update.zip包。在重啟進入Recovery模式之前,會向BCB中寫入命令,以便在重啟后告訴bootloader進入Recovery模式。Recovery:系統(tǒng)進入Recovery模式后會裝載Recovery分區(qū),該分區(qū)包含recovery.img(同boot.img相同,包含了標準的內(nèi)核和根文件系統(tǒng))。進入該模式后主要是運行Recovery服務(/sbin/recovery)來做相應的操作(重啟、升級update.zip、擦除cache分區(qū)等)。Bootloader:除了正常的加載啟動系統(tǒng)之外,還會通

6、過讀取MISC分區(qū)(BCB)獲得來自Main system和Recovery的消息。 Recovery模式工作原理 Recovery模式中的兩個通信接口:通過CACHE分區(qū)中的三個文件: mand:保存著Main system傳給Recovery的命令行/cache/recovery/log:Recovery模式在工作中的log打印/cache/recovery/intent:Recovery傳遞給Main system的信息通過BCB(Bootloader Control Block):BCB是bootloader與Recovery的通信接口,也是Bootloader與Main system

7、之間的通信接口。存儲在flash中的MISC分區(qū),占用三個page,其本身就是一個結(jié)構(gòu)體,具體成員以及各成員含義如下: struct bootloader_message char command32; /*在重啟進入Recovery模式時,會更新這個成員的值。另外在成功更新后結(jié)束Recovery時,會清除這個成員的值,防止重啟時再次進入Recovery模式*/ char status32;/*完成相應的更新后,Bootloader會將執(zhí)行結(jié)果寫入到這個字段*/ char recovery1024; /*Recovery操作過程中對命令操作的備份*/ ;Recovery模式工作原理在Main

8、System使用update.zip包進行升級時,系統(tǒng)會重啟并進入Recovery模式。在系統(tǒng)重啟之前,Main System會向BCB中的command域?qū)懭隻oot-recovery(粉紅色線),用來告知Bootloader重啟后進入recovery模式;重啟進入Recovery模式后Bootloader會從 mand中讀取值并放入到BCB的recovery域。而Main System在重啟之前會向 mand中寫入Recovery將要進行的操作命令。OTA升級OTA(Over The Air)升級就是通過空中接口獲取升級包,然后更新系統(tǒng)固件。一般地,升級包無論如何獲取,哪怕是直接通過存儲卡

9、本地升級,也被稱為OTA升級。OTA升級首要是生成OTA升級包,升級包又分為全量升級包和差分包升級包(增量升級包)。全量升級包是編譯當前系統(tǒng)得到的軟件包,這個包很大,可達上百兆,但是不依賴與當前終端里的軟件版本;增量升級包是對終端兩個軟件版本做差分,在第一個版本上打patch,得到第二個升級包,所以差分包只能對第一個版本的機器進行升級。 OTA升級的發(fā)起,就是通過向 mand里把“-update_package=”寫入,然后通過系統(tǒng)調(diào)用轉(zhuǎn)入內(nèi)核態(tài)執(zhí)行系統(tǒng)調(diào)用,實現(xiàn)機器重啟,完成OTA升級的全過程與本需求有關(guān)的安卓系統(tǒng)目錄/system/app系統(tǒng)默認的組件(預裝應用),目錄下文件以.apk格式

10、結(jié)尾/system/fonts字體文件夾, 新的中文字體或新增unicode字庫放在此文件夾/data/app用戶安裝應用,目錄下文件以.apk格式結(jié)尾/cache/recoveryupdate.zip 標準目錄結(jié)構(gòu)(全量升級包) 制作update.zip有兩種方法:手工制作:即按照update.zip的目錄結(jié)構(gòu)手動創(chuàng)建需要的目錄,然后將對應的文件拷貝到相應的目錄下。(不推薦,容易發(fā)生簽名不通過)命令制作: make otapackage,該命令在編譯源碼完成后并在源碼根目錄下執(zhí)行注:可以在包中添加userdata目錄,來更新系統(tǒng)中的用戶數(shù)據(jù)部分。這部分內(nèi)容在更新后會存放在系統(tǒng)的/data目錄

11、下在具體升級時,對update.zip包檢查時大致會分三步:檢驗SF文件與RSA文件是否匹配。檢驗MANIFEST.MF與簽名文件中的digest是否一致。檢驗包中的文件與MANIFEST中所描述的是否一致。 對應系統(tǒng)system分區(qū) kernel+ramdisk 簽名定義了與包的組成結(jié)構(gòu)相關(guān)的數(shù)據(jù)update.zip (增量升級包) 生成差分包調(diào)用的是文件./build/tools/releasetools/ota_from_target_files中的WriteIncrementalOTA方法,調(diào)用時需要將兩個版本的差分資源包作為參數(shù)傳進來,形如:./build/tools/release

12、tools/ota_from_target_files n i ota_v1.zip ota_v2.zip update.zip其中,參數(shù)n表示忽略時間戳;i表示生成增量包(即差分包);ota_v1.zip與ota_v2.zip分別代表前后兩個版本的差分資源包;而update.zip則表示最終生成的差分包。WriteIncrementalOTA函數(shù)會計算輸入的兩個差分資源包中版本的差異,并將其寫入到差分包中;同時,將updater及生成腳本文件udpate-script添加到升級包中。 APK升級 ROM升級 應用市場升級目錄應用市場原理APK開發(fā)者將應用發(fā)布至應用市場,用戶可在應用市場自主選

13、擇需要安裝的APK。除官方應用市場(Google Play)外,有許多第三方市場可供選擇。在安卓生態(tài)圈中,應用市場作為一個平臺,聯(lián)系起了開發(fā)者、用戶與運營商。應用市場主要分為三個部分:客戶端:通常為安裝在安卓終端的一個APK,支持查詢、下載、安裝、卸載、更新檢測、評分、推送等功能。面向終端用戶。應用發(fā)布管理:通常為Web前端,提供APK上傳、APK簽名管理、宣傳媒體(如截圖、視頻等)上傳、填寫應用信息(如描述、語言、版本說明等)、發(fā)布設置(如定價、發(fā)布地區(qū)、副本保護、內(nèi)容評分等)、應用審核等功能的操作入口。面向開發(fā)者和運營商。服務端:實現(xiàn)相應的客戶端和應用發(fā)布管理的后臺功能,主要組件包括數(shù)據(jù)庫

14、、Web服務、功能實現(xiàn)模塊等。 主動推送常見實現(xiàn)方式 所用原理輪詢(Pull)方式:應用程序階段性地與服務器進行連接并查詢是否有新的消息到達,應用程序必須實現(xiàn)與服務器之間的通信,例如消息排隊等。而且還要考慮輪詢的頻率,如果太慢可能導致某些消息的延遲,如果太快,則會大量消耗網(wǎng)絡帶寬和電量。持久連接(Push)方式:利用Socket維持Client和Server間的一個TCP長連接,通過這種方式可大大降低由輪詢方式帶來的數(shù)據(jù)訪問流量和耗電量常見實現(xiàn)方式GCM(Google Cloud Messaging for Android):以前叫C2DM, Google提供的用來幫助開發(fā)者從服務器向Andr

15、oid應用程序發(fā)送數(shù)據(jù)的服務,依賴于官方服務器。國內(nèi)各大平臺有推出GCM的替代品,如百度的云推送。MQTT:一個輕量級的消息發(fā)布/訂閱協(xié)議RSMB(Really Small Message Broker ):一個簡單的MQTT代理XMPP:安卓平臺信息推送框架AndroidPn(Android Push Notification)即是基于XMPP實現(xiàn),包含了完整的服務端和客戶端; HTTP輪詢:定時向HTTP服務端接口(Web Service API)獲取最新消息第一部分:需求說明第二部分:技術(shù)原理分析第三部分:需求分析與解決方案第四部分:問題、難點與風險第五部分:方案總結(jié)目錄需求分析原生安卓

16、系統(tǒng)為手機、平板而設計(Google正在推出針對Google TV的新版本,但因國情,引入可能性不大);移植至電視屏,需做許多改動,如:去除通信、GPS定位等功能,修改用戶操作等。根據(jù)廣電特點,需做到平臺內(nèi)容的可管可控,因此需要對內(nèi)容入口進行控制。終端升級類需求,主要約束對象為:應用APK歸屬于華數(shù)、屬于基礎業(yè)務的預裝應用(如DVB APK,VOD APK,Player APK,DTMB APK)歸屬于華數(shù)、屬于增值業(yè)務的可選應用ROM升級端運營管理類需求,主要約束對象為:OTA升級:針對預裝應用、ROM應用市場:針對用戶安裝應用,區(qū)別于移動互聯(lián)網(wǎng)應用市場,需收緊入口。終端升級類需求評估根據(jù)前

17、文技術(shù)原理分析可發(fā)現(xiàn),安卓提供的機制已基本支持終端升級類需求。具體需求實現(xiàn)思路如下:編號需求類別需求描述解決方案備注1升級方式自動升級(主動推送)OTA升級服務器主動推送2手動升級(手動查詢)用戶在終端觸發(fā),終端訪問OTA升級服務器3升級通道IP網(wǎng)絡升級(ROM與各APK升級)OTA4Cable網(wǎng)絡升級(ROM與DVB APK升級)前提:Cable網(wǎng)絡可訪問OTA升級服務器;Cable網(wǎng)升級方式需要進行驗證5U盤升級(ROM升級)OTA(存儲卡)如若支持,則有用戶替換運營商系統(tǒng)風險,是否需要支持?6升級包內(nèi)容ROM全量升級OTA7ROM增量升級OTA8APK自升級華數(shù)應用通過OTA升級服務器,

18、用戶安裝APK由應用商城或APK本身后端系統(tǒng)管理9應用商城升級應用商城10升級模式推送升級OTA11斷點續(xù)傳升級升級包的斷點續(xù)傳,考慮兩種情況:1.用戶主動暫停升級包下載(需考慮UI界面不卡死);2.下載異?;蛑袛?2靜默升級APK靜默升級可通過調(diào)用安卓pm命令實現(xiàn)或調(diào)用隱藏靜默升級接口;ROM靜默升級可考慮采用雙rom實現(xiàn)Pm命令要求root權(quán)限或系統(tǒng)簽名;安卓并未提供標準的靜默升級API(SDK中沒有),但在android.content.pm包中有系統(tǒng)隱藏API,只能是系統(tǒng)用戶組的apk才能調(diào)用隱藏接口,并需要簽名13升級校驗MD5校驗、RSA非對稱加密、apk數(shù)字簽名、ROM簽名均有標

19、準方法可實現(xiàn)運營管理類需求評估編號需求類別需求描述解決方案備注升級規(guī)模系統(tǒng)并發(fā)支持的升級項目無數(shù)量限制軟件方面:修改Web服務器支持的默認最大http連接數(shù)(如Apache默認150),修改Linux系統(tǒng)socket最大連接數(shù)的各種限制(包括:用戶可打開文件數(shù)、網(wǎng)絡內(nèi)核對TCP連接有關(guān)限制),使用高并發(fā)網(wǎng)絡I/O編程技術(shù);硬件方面:服務器方案、網(wǎng)絡方案、節(jié)點方案等軟件改動需配合硬件進行性能測試;應根據(jù)具體的業(yè)務需求規(guī)模進行合理設計分區(qū)域升級區(qū)域最小顆粒度能支持到區(qū)縣可考慮使用文件存放用戶區(qū)域信息(可考慮存放在/etc),區(qū)域信息獲取可通過BOSS反寫(需要相應反寫APK,并具備/etc寫權(quán)限)

20、或出庫adb寫入。更新時要求更新APK具有區(qū)域信息文件的讀權(quán)限。OTA或應用市場提供區(qū)域選擇。在推送更新時下發(fā)區(qū)域信息,終端收到推送信息時與本機信息比對,檢測是否升級;終端主動進行升級檢測時,可將本地信息作為參數(shù)與服務端通信,或先獲取服務端信息再與本地對比安卓提供的標準定位方法有GPS定位和網(wǎng)絡基站定位。在廣電智能終端上無法滿足分區(qū)域運營需求。按匹配規(guī)則升級能根據(jù)TVID進行精確與模糊匹配升級,具體匹配規(guī)則可支持等于、不等于、包含、不包含、*通配符、通配符、不做判斷依據(jù)等條件。要求OTA后臺、應用市場后臺可同步BOSS里的TVID信息,要求OTA后臺、應用市場后臺支持正則表達式匹配規(guī)則。要求終

21、端升級程序、市場客戶端、預裝APK具備讀取設備號(TVID)權(quán)限。不建議在用戶安裝的應用上使用此種升級方式。能根據(jù)軟件版本號進行.? 意義?能根據(jù)硬件(固件)版本號進行要求硬件(固件)版本號能同步到OTA后臺、應用市場后臺,可考慮由BOSS保存硬件(固件)版本號并同步給OTA后臺、應用市場后臺,要求OTA后臺、應用市場后臺支持正則表達式匹配規(guī)則。要求終端升級程序、市場客戶端、預裝APK具備讀取硬件(固件)版本號權(quán)限。不建議在用戶安裝的應用上使用此種升級方式。能根據(jù)區(qū)域、TVID、軟件版本、硬件版本等條件配置待升級終端分組。升級策略可支持策略匹配與終端分組匹配模式。參考以上強制升級支持強制升級與

22、非強制升級模式,強制模式用戶不可取消升級操作。(包括靜默升級)強制升級參考靜默升級按時間段升級支持對升級有效周期的控制,比如可控制升級在4月1日至4月20日某個時間段(00:0019:00、20:0023:59)有效。OTA后臺、應用市場后臺支持時間策略。終端支持時間策略。下載速度受網(wǎng)絡限制解決方案通過上述分析可知,為實現(xiàn)需求,需要完成的工作主要有:應用APK開發(fā) 歸屬于華數(shù)、屬于基礎業(yè)務的預裝應用(如DVB APK,VOD APK,Player APK,DTMB APK),需在開發(fā)時為其指定升級地址,涉及升級服務器域名規(guī)劃歸屬于華數(shù)、屬于增值業(yè)務的可選應用,需在開發(fā)時為其指定升級地址或指定其升級地址解析方式為華數(shù)應用市場 ROM升級需在操作系統(tǒng)中集成應用或服務,可訪問華數(shù)OTA升級服務器OTA升級

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論