安卓是如何逃脫gpl協議的

A. 如何重寫軟體以規避GPL協議

無論與哪個組織合作，只要涉及到法律問題，都需要與版權所有者簽訂合約。一些開發人員可能不願意與免費軟體基金會簽訂合約。我個人對與FSF合作沒有任何異議，但是一些人認為這沒有必要。一些人錯誤地認為免費軟體基金會實際上就是Richard Stallman（免費軟體基金會主席），還有一些人對Richard有意見。一些人非常惡意地指責GPL許可協議是一種商業性行為，對此你有什麼看法？
這是一個富有哲學意義的問題。BSD licence允許你在無需標注原程序的情況下對程序進行修改，但是GPL則需要註明原有程序的出處。這是開發軟體時應該注意到的問題。

B. 安卓系統怎麼控制對linux的驅動程序，比如對I/O口的控制

安卓系統貌似刪除了部分遵從GPL協議的linux驅動，自己實現的很多底層控制，我這個了解不多，不好意思，幫不到你了

C. 安卓系統是什麼公司的，一般手機是使用正版還是盜版

安卓手機是谷歌公司與眾多手機廠商，移動運營商共同開發的，未經谷歌公司許可，講安卓系統裝入手機中是合法的，因為android是基於linux，而Linux遵循GPL協議，所以安卓也遵循GPL協議，必須開源（也就是開放源代碼，有了
源代碼，其他程序員就能隨意的修改安卓系統）

D. 國產操作系統不就是Linux開發的嗎這系統不是國外的嗎為什麼還要說是國產的呢

使用linux內核為原型的的開發，不能算「國產」操作系統。
只能稱之為「漢化」或者是「特定的linux發行版本」。
漢化或特定的linux版本可以開發出特定的功能，如更好的支持辦公、移動、或特別的安全等目的。
至於經費什麼的，有時候出於特別的需求，也是合理的。比如為某個項目如環境檢測、地質勘探或軍事項目定製操作系統，這個肯定不能算騙錢。
但是以linux內核為基礎開發了一個發行版本，就直接說是國產操作系統的，就肯定是騙子了。

E. 為什麼安卓現在還不閉源

GPL開源協議的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用，但不允許修改後和衍生的代碼做為閉源的商業軟體發布和銷售。安卓是基於Linux的，Linux是GPL開源協議，所以安卓想閉源必須剔除Linux內核，看起來不可能。

F. gpl是什麼卡通道

GPL（GNU通用公共許可證）是大多數軟體許可證。
GPL許可協議是只要軟體中包含有其他GPL協議的產品或代碼，那麼該軟體就必須也採用GPL許可協議且開源及免費。具有復制自由、傳播自由、收費傳播、修改自由的特點。
Android是基於Linux內核開發的，Linux內核是GPL授權。內核模塊屬於Linux內核的衍生產品，需要遵守GPL協議開源發布。因此安卓引入HAL，給linux內核開了個後門，增加了一些系統調用。HAL在內核的部分按照GPL的要求開源。驅動開發者可以在用戶態使用這些新增的系統調用完成驅動的開發。從而在驅動方面規避了GPL。

G. gpl和android的問題

修改基於GPL的源碼或使用其中的部分源碼，會受到GPL傳染而需以GPL許可發布。所以安卓在LINUX內核上修改得到的安卓內核是以GPL V2發布的，但是谷歌很聰明它的安卓系統的用戶層的開發只使用了內核提供的介面，這讓它不受傳染，而不需以同樣的許可發布。

H. 安卓中的Binder架構是什麼為什麼要提供Binder

1）從性能的角度數據拷貝次數：Binder數據拷貝只需要一次，而管道、消息隊列、Socket都需要2次，但共享內存方式一次內存拷貝都不需要；從性能角度看，Binder性能僅次於共享內存。（2）從穩定性的角度Binder是基於C/S架構的，簡單解釋下C/S架構，是指客戶端(Client)和服務端(Server)組成的架構，Client端有什麼需求，直接發送給Server端去完成，架構清晰明朗，Server端與Client端相對獨立，穩定性較好；而共享內存實現方式復雜，沒有客戶與服務端之別， 需要充分考慮到訪問臨界資源的並發同步問題，否則可能會出現死鎖等問題；從這穩定性角度看，Binder架構優越於共享內存。僅僅從以上兩點，各有優劣，還不足以支撐google去採用binder的IPC機制，那麼更重要的原因是：（3）從安全的角度傳統Linux IPC的接收方無法獲得對方進程可靠的UID/PID，從而無法鑒別對方身份；而Android作為一個開放的開源體系，擁有非常多的開發平台，App來源甚廣，因此手機的安全顯得額外重要；對於普通用戶，絕不希望從App商店下載偷窺隱射數據、後台造成手機耗電等等問題，傳統Linux IPC無任何保護措施，完全由上層協議來確保。 Android為每個安裝好的應用程序分配了自己的UID，故進程的UID是鑒別進程身份的重要標志，前面提到C/S架構，Android系統中對外只暴露Client端，Client端將任務發送給Server端，Server端會根據許可權控制策略，判斷UID/PID是否滿足訪問許可權，目前許可權控制很多時候是通過彈出許可權詢問對話框，讓用戶選擇是否運行。Android 6.0，也稱為Android M，在6.0之前的系統是在App第一次安裝時，會將整個App所涉及的所有許可權一次詢問，只要留意看會發現很多App根本用不上通信錄和簡訊，但在這一次性許可權許可權時會包含進去，讓用戶拒絕不得，因為拒絕後App無法正常使用，而一旦授權後，應用便可以胡作非為。針對這個問題，google在Android M做了調整，不再是安裝時一並詢問所有許可權，而是在App運行過程中，需要哪個許可權再彈框詢問用戶是否給相應的許可權，對許可權做了更細地控制，讓用戶有了更多的可控性，但同時也帶來了另一個用戶詬病的地方，那也就是許可權詢問的彈框的次數大幅度增多。對於Android M平台上，有些App開發者可能會寫出讓手機異常頻繁彈框的App，企圖直到用戶授權為止，這對用戶來說是不能忍的，用戶最後吐槽的可不光是App，還有Android系統以及手機廠商，有些用戶可能就跳果粉了，這還需要廣大Android開發者以及手機廠商共同努力，共同打造安全與體驗俱佳的Android手機。Android中許可權控制策略有SELinux等多方面手段，下面列舉從Binder的一個角度的許可權控制：Android源碼的Binder許可權是如何控制？ -Gityuan的回答傳統IPC只能由用戶在數據包里填入UID/PID；另外，可靠的身份標記只有由IPC機制本身在內核中添加。其次傳統IPC訪問接入點是開放的，無法建立私有通道。從安全形度，Binder的安全性更高。說到這，可能有人要反駁，Android就算用了Binder架構，而現如今Android手機的各種流氓軟體，不就是干著這種偷窺隱射，後台偷偷跑流量的事嗎？沒錯，確實存在，但這不能說Binder的安全性不好，因為Android系統仍然是掌握主控權，可以控制這類App的流氓行為，只是對於該採用何種策略來控制，在這方面android的確存在很多有待進步的空間，這也是google以及各大手機廠商一直努力改善的地方之一。在Android 6.0，google對於app的許可權問題作為較多的努力，大大收緊的應用許可權；另外，在Google舉辦的Android Bootcamp 2016大會中，google也表示在Android 7.0 （也叫Android N）的許可權隱私方面會進一步加強加固，比如SELinux，Memory safe language(還在research中)等等，在今年的5月18日至5月20日，google將推出Android N。 （4）從語言層面的角度大家多知道Linux是基於C語言(面向過程的語言)，而Android是基於Java語言(面向對象的語句)，而對於Binder恰恰也符合面向對象的思想，將進程間通信轉化為通過對某個Binder對象的引用調用該對象的方法，而其獨特之處在於Binder對象是一個可以跨進程引用的對象，它的實體位於一個進程中，而它的引用卻遍布於系統的各個進程之中。可以從一個進程傳給其它進程，讓大家都能訪問同一Server，就像將一個對象或引用賦值給另一個引用一樣。Binder模糊了進程邊界，淡化了進程間通信過程，整個系統彷彿運行於同一個面向對象的程序之中。從語言層面，Binder更適合基於面向對象語言的Android系統，對於Linux系統可能會有點「水土不服」。另外，Binder是為Android這類系統而生，而並非Linux社區沒有想到Binder IPC機制的存在，對於Linux社區的廣大開發人員，我還是表示深深佩服，讓世界有了如此精湛而美妙的開源系統。也並非Linux現有的IPC機制不夠好，相反地，經過這么多優秀工程師的不斷打磨，依然非常優秀，每種Linux的IPC機制都有存在的價值，同時在Android系統中也依然採用了大量Linux現有的IPC機制，根據每類IPC的原理特性，因時制宜，不同場景特性往往會採用其下最適宜的。比如在Android OS中的Zygote進程的IPC採用的是Socket（套接字）機制，Android中的Kill Process採用的signal（信號）機制等等。而Binder更多則用在system_server進程與上層App層的IPC交互。(5) 從公司戰略的角度總所周知，Linux內核是開源的系統，所開放源代碼許可協議GPL保護，該協議具有「病毒式感染」的能力，怎麼理解這句話呢？受GPL保護的Linux Kernel是運行在內核空間，對於上層的任何類庫、服務、應用等運行在用戶空間，一旦進行SysCall（系統調用），調用到底層Kernel，那麼也必須遵循GPL協議。 而Android 之父 Andy Rubin對於GPL顯然是不能接受的，為此，Google巧妙地將GPL協議控制在內核空間，將用戶空間的協議採用Apache-2.0協議（允許基於Android的開發商不向社區反饋源碼），同時在GPL協議與Apache-2.0之間的Lib庫中採用BSD證授權方法，有效隔斷了GPL的傳染性，仍有較大爭議，但至少目前緩解Android，讓GPL止步於內核空間，這是Google在GPL Linux下 開源與商業化共存的一個成功典範。