⑴ android應用伺服器防火牆如何設置
Android網路防火牆的幾種實現方式
a) Android應用層：敏感函數hook
i. 絕大多數Android應用都是調用Android Framework來實現網路通訊。比如：webView.loadUrl()，HttpClient.execute()，DefaultHttpClient.execute()等。只需窮舉這些類的函數，並將它們都Hook住，這樣就可實現攔截上網的功能了。
ii. 當然，如果想要Hook這些函數入口，有兩種方式：1. 首先需要獲得root許可權，然後通過進程注入，將Client代碼注入到應用進程，在進程上網時，應用進程將會發起IPC請求到Server進程，由Server進程來決定是否允許其訪問網路。2. 通過修改應用本身來加入Hook代碼，從而避免了root手機，這樣相對比較安全。
iii. 使用函數hook這種方案的優點是：簡單、快速、可實現網路熱開關(無需殺死進程)。但缺點是也是有的，它不能攔截所有的網路訪問入口。例如：某應用如果沒有調用Android的庫，而是自己實現了一個訪問網路的庫，或者甚至用native代碼來實現，那麼這時候這個方案將攔截不到任何的上網請求。
⑵ 手機怎樣關閉防火牆
安卓手機關閉防火牆方法一
1、如果該防火牆不是系統自帶的，是你下載安裝的，就直接在設置選項中，選擇應用程序--管理應用程序，找到防火牆程序，直接卸載、重啟即可。
2、如果該防火牆是系統自帶的，無法直接刪除，請先把系統root 了，提高了管理許可權後，再把防火牆刪除就行了。
安卓手機關閉防火牆方法二
1.黑白名單管理：黑白名單為用戶拒絕接受來電和信息的號碼列表;可自行添加攔截短息和過濾詞。
2.白名單為用戶願意接受簡訊和來電的號碼列表;黑白名單使用范圍：簡訊及來電、簡訊或來電。
3.攔截記錄：查看攔截的簡訊和來電的記錄清單，可以對已攔截的信息進行回電、恢復或恢復到手機收件箱。
4.攔截規則: 系統提供了7種攔截規則提供用戶使用。
5.用戶可根據自己的需要選擇一種規則。
6.設置中心：設置中心可以對服務開啟/關閉、開機自啟動、攔截信息通知、攔截來電方法等功能進行設置。
相關閱讀：
防火牆相關功能
防火牆具有很好的保護作用。入侵者必須首先穿越防火牆的安全防線，才能接觸目標計算機。你可以將防火牆配置成許多不同保護級別。高級別的保護可能會禁止一些服務，如視頻流等。
防火牆最基本的功能就是控制在計算機網路中，不同信任程度區域間傳送的數據流。例如互聯網是不可信任的區域，而內部網路是高度信任的區域。以避免安全策略中禁止的一些通信，與建築中的防火牆功能相似。它有控制信息基本的任務在不同信任的區域。 典型信任的區域包括互聯網(一個沒有信任的區域)和一個內部網路(一個高信任的區域)。最終目標是提供受控連通性在不同水平的信任區域通過安全政策的運行和連通性模型之間根據最少特權原則。
例如：TCP/IPPort 135~139是Microsoft Windows的【網上鄰居】所使用的。如果計算機有使用【網上鄰居】的【共享文件夾】，又沒使用任何防火牆相關的防護措施的話，就等於把自己的【共享文件夾】公開到Internet，供不特定的任何人有機會瀏覽目錄內的文件。且早期版本的Windows有【網上鄰居】系統溢出的無密碼保護的漏洞(這里是指【共享文件夾】有設密碼，但可經由此系統漏洞，達到無須密碼便能瀏覽文件夾的需求)。
防火牆對流經它的網路通信進行掃描，這樣能夠過濾掉一些攻擊，以免其在目標計算機上被執行。防火牆還可以關閉不使用的埠。而且它還能禁止特定埠的流出通信，封鎖特洛伊木馬。最後，它可以禁止來自特殊站點的訪問，從而防止來自不明入侵者的所有通信
⑶ 安卓上有沒有無需ROOT就可以禁用應用許可權的東西
1 為什麼Android總是事無巨細地告訴你應用索取的每一項許可權？
相比Apple，Microsoft嚴格控制生態系統（從蘋果給開發者的「App Store Guideline」可見一斑），只允許通過官方應用商店安裝應用，並對每份上傳進行仔細地審查而言，Android的開放就意味著，Google需要向 用戶提供一系列用於為自己負責的流程、工具。所以在安裝應用前，Android總是要事無巨細地告訴你，應用肯需要控制什麼許可權。
同樣，開發者也製作了一系列易用的工具，用以鑒別可疑的應用程序，或是控制許可權。
圖1 Android 官方市場會強制提醒用
Andoird哪裡開放了？
在Android中，用戶能自由從本地安裝應用，自由地對SD卡進行操作，自由選擇應用市場。
如果願意放棄保修，用戶還能輕易地實行root，解鎖基帶（baseband）。只有一些產品會嚴密地鎖定bootloader（如摩托羅拉）。
最重要的是，因為ASOP（Android源代碼開放計劃）的存在，絕大部分的Android代碼都是開源的，開發者可以由此對Android系統進行 深入的修改，甚至可以自行編寫一個符合Android規范的系統實例（如Cyanogen Mod）。正是因為ASOP，這篇文章才可能介紹多達5種原理不同的許可權控制方法。
圖2 Android開源計劃的標志
開放的風險
不考慮Symbian，Windows Phone 6.5（及以下）平台，那麼幾乎所有的智能手機病毒都是Android平台的，甚至官方Android Market也鬧過幾次烏龍。在國內水貨橫行的市場，情況更是火上澆油，不法業者可以在手機的ROM，甚至是bootloader中做好手腳，讓用戶有病無法醫。
在Android中，用戶可以允許系統安裝來自「未知源」（也就是非Google官方的，或手機預置市場的）應用程序。於是，移動平台最重要的門神------數字簽名就被繞過了。
圖3 Android 允許未知安裝未知來源的應用程
出於Android的開放性，也有不允許「未知源」的反例：亞馬遜的Kindle Fire平板使用了深度定製的Android，它只允許安裝來自亞馬遜官方商店的應用程序。
圖4 亞馬遜的 Kindle Fire 僅允許通過自帶的市場安裝應用
2 Android有哪些「許可權」
首先需要明確一下Android中的種種「許可權」。Android是在Linux內核上建立一個硬體抽象層（Android HAL），通過Dalvik以及各種庫來執行android應用的。在手機啟動時，首先需要由Bootloader（HTC手機上稱作Hboot）引導 Linux及手機上各個硬體設備的驅動程序，之後才啟動Android系統。所以其實我們會涉及到四種不同涵義的許可權：
Android許可權（Permission）
這指Android中的一系列「Android.Permission.*」對象，是本文的中心內容。
Google在Android框架內把各種對象（包括設備上的各類數據，感測器，撥打電話，發送信息，控制別的應用程序等）的訪問許可權進行了詳細的劃 分，列出了約一百條「Android.Permission」。應用程序在運行前必須向Android系統聲明它將會用到的許可權，否則Android將會 拒絕該應用程序訪問通過該「Permission」許可的內容。
比方說，搜狗輸入法提供了一個智能通訊錄的功能，用戶可以在輸入聯系人 拼音的前幾個字元，或首字母，輸入法就能自動呈現相關聯系人的名字。為了實現這個功能，輸入法必須聲明它需要讀取手機中聯系人的能力，也就是在相關代碼中 加上聲明「android.permission.READ_CONTACTS」對象。
圖5 搜狗輸入法的智能聯系人功能
原生Android只提供了對「一刀切」式的管理，要麼同意使用，否則就根本就不安裝應用程序。當用戶遇到希望使用程序的同時，又想禁止部分Permission的場合，他就無路可走。
於是，不少開發者就搗鼓出了「第三條道路」；可惜的是，沒有一種方法能同時做到既不需要將手機固件Root，又完全不涉及對原始應用程序進行反向工程的方法。
Root
Root指獲得Android所在的Linux系統的Root（根）許可權，有了根許可權，你才能對Linux做出任意的修改。iOS中的越獄 （Jailbreak） 相當於獲得iOS系統的Root許可權（iOS是一種類Unix系統，和Linux都使用Root的概念）。在已Root的設備中，通常都是使用一個 叫「Superuser」（簡稱SU）的應用程序來向許可的程序授以Root許可權。
Bootloader的解鎖（Unlock）
利用數字簽名，Bootloader可以限定只有正確簽名的系統可以被引導。在修改固件以獲得Root以前，解鎖Bootloader通常是必須的。安裝第三方修改、編譯的固件也需要解鎖Bootloader。
基帶（Radio）解鎖
在Android系統中，基帶是上層軟體與手機中無線設備（手機網路，Wi-Fi，藍牙等）的驅動程序之間的中介。國外的網路運營商很喜歡鎖定基帶，從 而保證用戶只能使用運營商自己指定的sim卡。在我國，鎖定基帶是非法的，手機製造商、網路運營商也不可以通過鎖定基帶的方法對待違約客戶。iOS的「解 鎖」就是解鎖iOS中的基帶軟體。
為什麼要控制Android許可權
魚和熊掌不可兼得，Android的世界有很多自由，壞人也能自由地做壞事。它的生態系統很強調自主：用戶可以自主地減小風險，僅使用官方市場的應用程序，也可以自主地解除安全限制，從而獲得更多自由。因此，在遇到壞事的時候，用戶也不得不自主一下：
1， 抵制不道德，乃至非法行為
幾乎所有的Android安全軟體都能對來電、信息進行控制，以減少騷擾。
另一方面，很多應用都會要求它們實際功能以外的許可權，表現在非（主動）告知地搜集設備序列號，位置信息，誘使用戶默認地上傳聯系人列表等方面。
更壞一點的應用程序，則會踏入犯罪的范疇，比如能偷偷發出扣費信息，或是作為黑客的偷窺工具。
2， 減少惡意軟體的損害
惡意軟體即便潛伏成功，也難以獲得許可權，從而減少損失。
3， 用戶有權自主地在抑制應用程序的部分許可權時，繼續使用該應用程序，而只承擔由於自行設置不當而帶來的後果。
用戶擁有設備的所有權，因此有權自主控制設備上的內容、感測器等對象的訪問；同時有權（不）運行，（不）編譯設備上的應用程序。
大多數應用程序在運行時，並未達成主動告知的義務，是失誤；然而即使主動告知，用戶還是可以不理會。
為什麼Android官方市場的強制提醒許可權的行為不屬於主動告知：
通過Android官方市場，「打包安裝器」安裝應用程序時，所顯示的「許可權」僅是在安裝包內AndroidManifest.xml聲明的值，而非應 用程序實際上會調用的內容。該值僅用來表明Android系統能向應用授予的最大可能的許可權。即便一個「Hello World」式的應用程序，也可以在AndroidManifest.xml中聲明所有可能的Android Permission。
這就是說，在AndroidManifest.xml中聲明的值與應用程序實際調用的許可權有關聯，但不等同，且這種提示是由Android系統負責實施的強制行為。
正確的理解是：「應用程序（被迫地）讓Android系統告知用戶，它在AndroidManifest.xml中所聲明的事項。」
這意味著應用程序在使用重要許可權前，依然需要自行、主動地通知用戶相關事宜。
圖6 應用程序須要AndroidManifest.xml中聲明調用到的許可權
然而，即便只是讓一半的應用程序達到以上的標准，也是不可能的。應用程序需要通過收集用戶信息，程序的錯誤日誌。從而統計用戶的喜好，改進程序。另一方 面，這也是發送精確廣告但不追溯到用戶身份信息的方式，這一點對於免費應用而言，是極其重要的。我們之所以能知道不同型號手機的佔有率，應用軟體的流行 度，是與這樣的統計不可分離的。
一旦每個應用程序都專業地主動發出提醒，不專業的用戶（大多數用戶都是不專業的）通常會將之視為如同海嘯警報一般的危機。
這么做對誰都沒有好處------用戶方的隱私權是毋庸置疑的，然而應用程序方面的獲取信息記錄的需求也是無可阻擋的。如果每個用戶都打算阻止，只會落得被迫接受不平等條約的下場，在溫飽以前，不會有人考慮小康的問題。
於是，現狀就變得有趣：用戶人享受著相同的服務；其中大部分用戶出於不知情/好意，默默地向開發者、廣告商提供了信息，剩下的少數用戶則能阻斷這種勞務。而作為維持Android平台的信息商人Google，只確保在它的地盤里，不會發生觸碰底線的事情。
一句話總結：
設備是我的，不管你怎麼說，反正我說了算，但我說的話大多是不算數的。
3 許可權控制的方法
這里開始介紹各種控制Android許可權的辦法。可惜的是，幾乎所有的手段都需要對設備進行Root，如果不這么做，則需要付出不小代價。
App Shield（國內常見的名字：許可權修改器）
它是一個需要付費的Android應用，其原理是修改應用程序的apk安裝包，刪除其中AndroidManifest.xml文件內，用於聲明許可權的 對應「Android.Permission.*」條目，然後再用一個公開的證書對安裝包重新簽名（需要允許「未知源」），這樣一來，應用程序就不會向系 統申請原先所需的許可權。當應用運行至相應的流程時，系統將直接拒絕，從而達到用戶控制許可權的目的。
對於已安裝的應用，AppShield也會按照同樣方法製作好apk安裝包，然後讓用戶先卸載原始的應用，再安裝調整過的應用。除了該應用數字簽名外，用戶可以隨時通過執行同樣的流程，將吊銷的許可權恢復。
圖7 AppShield
Apk文件的結構
Android應用都是打包成以.apk擴展名結尾，實際上是zip的文件格式。
一個合法的apk至少需要這些成分：
根目錄下的「AndroidManifest.xml」文件，用以向Android系統聲明所需Android許可權等運行應用所需的條件。
根目錄下的classes.dex（dex指Dalvik Exceptionable），應用（application）本身的可執行文件（Dalvik位元組碼） 。
根目錄下的res目錄，包含應用的界面設定。（如果僅是一個後台執行的「service」對象，則不必需）
Apk根目錄下的META-INF目錄也是必須的，它用以存放應用作者的公鑰證書與應用的數字簽名。
當應用被安裝後，這個apk文件會原封不動地移至設備的data/app目錄下，實際運行的，則是Dalvik將其中Classes.dex進行編譯後 的Classes.odex（存放在Dalvik緩存中，刷機時的『cache wipe就是清除Dalvik的odex文件緩存』）。
優點：
完全不需要Root，適用於所有版本的Android設備。不會損壞系統，可以吊銷任意一項Android許可權。
問題：
1，需要重新安裝應用，該行為可能會丟失應用的配置、歷史記錄。
2，執行許可權吊銷的應用的數字簽名會被更改，無法直接更新。對於那些設計不良（沒有意料到『不聲明許可權』情況的），或有額外自校驗的應用，可能會無法運行。
3，無法用於設備上的預裝應用，除非製造商好心地將該應用設置為「可以刪除」的狀態。
4，這個方法修改了apk包中的內容------盡管實際上AndroidManifest.xml和數字簽名並不算是應用程序的本身，但修改它們可能引發著作權的問題。
5，需要開啟「未知源」。
6，這是一個收費應用。
CyanogenMod 7.1（及以上版本）
Cyanogenmod是一款著名的第三方編寫的開源Android ROM。
CM7.1加入了控制許可權的開關，官方的名稱是「Permission Revoking」，任何非系統/保護應用在安裝後，可直接吊銷任意一項許可權，其效果等價於直接刪除apk包中AndroidManifest.xml的 對應條目，但不會引發自校驗的問題。CM的許可權工具的作用等同於AppShield，無非是在Android自身的許可權系統中添加了一個開關。
圖8 Cyanogen Mod 7.1中的許可權吊銷（Permission Revoking）設定
優點：
免費，使用簡便，可隨時，任意地吊銷、恢復非預裝應用的任意一項許可權；不存在數字簽名的問題，因而不影響使用自校驗的應用程序。
問題：
此功能僅在Cyanogen Mod 7.1及以上版本提供，無法用於其它rom。因為是由Android系統出面吊銷許可權，其實現原理與App Shield完全相同，同樣的，應用程序會因為設計不良而出現崩潰。
Permission Denied
這是可以吊銷任意Android應用（注意，不當地吊銷系統應用的許可權可能會導致手機固件損壞，無法啟動）的任意許可權，對許可權的修改在重啟後生效。
實現原理應該與Cyanogen Mod 7.1+完全相同，適用於任何已經Root的系統，因為一般的Android系統雖然事實上支持許可權吊銷，但沒有像Cyanogen Mod那樣放置介面，因此需要重啟後才能應用許可權配置。同樣也有系統出面拒絕許可權而導致的崩潰現象。
圖9 Permission Denied免費版吊銷應用程序許可權的場景
優點：
效果與Cyanogen Mod中的許可權吊銷效果一致，且可吊銷系統應用的許可權。同時提供了免費與收費版本，免費版並沒有基本功能的缺失。適用於所有版本號不低於1.6的Android設備。
問題：
調整後的許可權需要重啟才能生效。設計不良的應用會崩潰。不恰當的許可權修改會損壞系統，導致無法開機。
PDroid
PDroid實際上是一個Android內核補丁加上一個用於管理的外部應用。補丁需要在Recover環境中刷入系統，也可以由開發者自行移植入系 統。該軟體在Android ASOP 2.3.4代碼基礎上開發，僅適用於沒有改動內核的Android 2.3系統，目前還未支持Android 4。
圖10 PDroid的界面
為了避免Cyanogen Mod 7.1+許可權吊銷（Permission revoking）導致的崩潰問題，以及後台服務（如LBE，QQ手機管家等，PDroid的作者認為通過後台服務攔截許可權並不是好辦法），PDroid 並不阻止應用程序聲明許可權，但會在其實際索取相關信息時，予以阻止。通俗地說，就是簽署協議但不執行。在PDroid的用戶界面，用戶能隨時精確地控制涉 及隱私的各項許可權。對於某些內容，除了阻止外，用戶還可以偽造一個隨機或指定的數據。
可控制的內容包括：
IMEI（可偽造）
IMSI（可偽造）
SIM卡序列號（可偽造）
手機號碼（可偽造）
來，去電號碼
SIM卡信息
當前蜂窩網路信息
（以上七者均來自Android.Permission.READ_PHONE_STATE）
GPS定位信息 （可偽造，來自Android.Permission.FINE_LOCATION）
基站定位 （可偽造，來自Android.Permission.COARSE_LOCATION）
系統自帶瀏覽器的歷史，書簽（Android.Permission.BOOKMARKS）
聯系人 （android.permission.READ_CONTACTS）
通話記錄 （android.permission.READ_CONTACTS）
系統日誌 （android.permission.READ_LOGS）
當前賬戶列表 （android.permission.GET_ACCOUNTS）
當前賬戶的授權碼 （android.permission.USE_CREDENTIALS）
簡訊，彩信 （可能與這5個許可權有關）
android.permission.READ_SMS
android.permission.RECEIVE_SMS
android.permission.SEND_SMS
android.permission.WRITE_SMS
android.permission.RECEIVE_MMS
日歷 android.permission.READ_CALENDAR
PDroid的內核補丁並不通用，每一個Rom都需要特定的補丁。開發者除了提供了幾個特定機型下Cyanogen Mod，HTC Sense修改版ROM的專用補丁外，還推出了一個補丁生成工具（PDroid Patcher），用戶可以給自己的ROM生成專用的內核補丁。使用該Patcher需要安裝JDK（java Development Kit）。
優點：
PDroid避免了通過Android系統進行許可權吊銷的導致的潛在崩潰問題，也不需要後台服務。對隱私信息的控制是最精細的。盡管設備必須Root，但應用本身不需要Root許可權。
問題：
安裝過程是最繁瑣，最不可靠的，容易導致ROM損壞，適用范圍也小，需要用戶有相當的技能（能安裝JDK，會刷機）才可使用；只提供對隱私有關許可權的控制，不提供網路訪問，的控制。以這些為代價，它幾乎沒有其它缺點。
LBE安全大師
實際上最常用的是以LBE為代表的通過一個Root許可權的後台服務來攔截相關行為的工具。除了LBE外，還有QQ手機管家等應用。這里以LBE安全大師為例介紹。
圖11 LBE安全大師
LBE是國內一個叫「LBE安全小組」開發的工具，支持Android2.0～4.0。它的核心功能是像殺毒軟體一般，通過一個需要Root許可權的後台 服務，劫持所有調用許可權的行為，並放行用戶許可的部分（其官方宣傳為『API級別攔截』）。它和PDroid一樣幾乎不會引發應用程序崩潰，它支持攔截幾 個涉及用戶的關鍵許可權（LBE手機管家3.1/3.2）：
讀取簡訊 （android.permission.READ_CONTACTS）
聯系人記錄 （android.permission.READ_CONTACTS）
通話記錄 （android.permission.READ_CONTACTS）
定位 （Android.Permission.COARSE_LOCATION
Android.Permission.FINE_LOCATION）
手機識別碼 （與Android.Permission.READ_PHONE_STATE有關）
通話狀態 （與Android.Permission.READ_PHONE_STATE有關）
發送簡訊（具體原理不明，同樣類似於禁止這五個許可權
android.permission.READ_SMS
android.permission.RECEIVE_SMS
android.permission.SEND_SMS
android.permission.WRITE_SMS
android.permission.RECEIVE_MMS）
撥打電話 （android.permission.CALL_PHONE）
通話監聽 （android.permission.PROCESS_OUTGOING_CALLS）
除此以外，LBE還可以分別控制應用在Wifi，手機網路的聯網許可權，其原理是依靠IPtables防火牆，而非通過Android的「Internet」許可權。
此外LBE手機管家還提供基於智能內容審查的簡訊攔截、來電歸屬地顯示，以及禁用系統（保護）應用，進程管理，殺毒等功能。
LBE提供兩個版本，一個叫「LBE安全大師」，是一個全面的手機管家類應用，更新比較頻繁，另一個版本（LBE手機隱私衛士，LBE Security lite）僅提供許可權方面的管理。
考慮到主要市場在國內，LBE的發行策略看上去有些奇怪，它在Google的官方市場並不發行最新版。通常只能只能在LBE的官方網頁，以及國內的應用市場獲得最新版本。
優點：
使用非常簡單，功能強大而全面，風險很小，可以控制系統應用。適用范圍廣，有很多替代產品。
問題：
需要後台服務 （盡管蠶豆網有個評測，認為它對能耗幾乎沒有影響），不能控制所有的Android許可權。
4 .自啟動的控制
Android對後台服務有著最好的支持。
在Android中可以自由地開發一種稱為『Service』的後台運行的對象，加上沒有蘋果公司對應用程序的嚴格限制。諸如QQ掛機，即時調用第三方應用程序之類的形式都可以輕易實現。
為了全面支持後台服務，也為了適應移動設備資源緊張，不得不經常清理內存的問題，應用可在系統中設置觸發器，當系統發生了某個特定特定事件時（系統啟動，撥打電話，收發信息，安裝、卸載應用，插上電源等，或應用程序自行定義的事件），就會觸發啟動應用程序。
AutoStarts 自啟動管理
AutoStarts是一個收費應用，通過它，用戶能了解系統中每一項程序會在什麼場合下被觸發運行。如果提供Root許可權，則還能禁止這樣的行為。
這里以Google Maps應用6.2版為例。默認情況下，這款應用總是會保持後台運行，並每小時向Google發送一次當前用戶的位置信息。為了阻止這樣的行為，需要聯合 使用AutoStarts與任意一款進程管理應用：在AutoStarts中，阻止Google Maps的自行啟動（如圖），在每次使用完後，把Google Maps的進程殺掉。
圖12 AutoStarts可以對自啟動項目進行修改
5. 其他
Root帶來的風險
有一個鑽牛角尖的說法認為，一旦對設備進行了Root，便無安全一說，只要惡意程序一旦偷偷獲得Root級別，一切都是空談。
這種說法之所以鑽牛角尖，是因為：一方面Android中的Root許可權通常都是需要用戶通過Superuser應用進行授權的，這已經夠用，雖然不能 指望Superuser無懈可擊；另一方面，控制Android許可權主要是為了讓應用程序在「灰色地帶」的行為收斂一些，它們實際顯然不是病毒等犯罪軟 件。
著作權的問題 (作者不是法律方面的專家，以下言論僅供參考）
我們知 道，Android中的應用程序是基於Java語言編寫的。而為了達到跨平台的目的，Java軟體是以位元組碼（或叫中間代碼，bytecode），而非計 算機能直接執行的機器碼（Machine Code，有時也叫作Binary）的形式存在。因此執行Java軟體時，需要一個Java虛擬機（Android系統中的Java虛擬機就是 Dalvik）負責解釋運行，有的時候，虛擬機還會通過即時編譯（JIT）的方法將位元組碼編譯為機器碼後再運行，以提高程序的執行效率。
這就出現一個很有趣的現象：
除非另行規定，作為設備的擁有者，用戶總是可以自行決定如何使用軟體，能自行決定程序能否訪問用戶自己的計算機（移動設備亦然）裡面的各個內容、對象。
由此衍生出，在需要對代碼編譯、解釋的場合，用戶也能通過對編譯器（解釋器）的干預，來影響代碼的執行效果。在Android中，用戶還可以在Dalvik解釋、編譯的時候動手。
這是因為，著作權僅保護了軟體代碼不受到非授權的反向工程，未授權傳播等侵犯。另一方面，對於Android上的Java，網頁中的 javascript程序，賦予用戶解釋、編譯的權利是程序能執行的先決條件；同時，軟體發行者發通常也會主動提出放棄這種權利（表現為『軟體按原樣提供 』、『不對使用軟體造成的後果負責』等條目）
在編譯、解釋的過程中，需要通過匯編（Assemble），連接（Link）等方法將編譯 好的對象（Object）、方法（Function）聯系起來。默認情況下，這些行為是由原始的代碼（源代碼、中間代碼）與編譯器（解釋器）決定的，但是 用戶可以通過制約編譯器（解釋器）的設置，從而影響到最終代碼。這么做是沒有問題的。
還有一種，應用程序在安裝後，會在系統中產生一些 緩存，或注冊一些信息。當其中的內容有關用戶數據時，讀取或修改它們也是沒有問題的。這就是所謂「只要是你的東西總是你的」；也是Cyanogen Mod、Permission Denied不會涉及版權問題的原因所在。
總之，一個Android應用之所以能運行的前提是：
1，首先，用戶允許使用這個應用
這也可以理解成：用戶安裝了應用（以及因此設定的後台對象），購買了預裝應用的手機。這一點即不影響應用程序的主動通知義務，也不影響用戶事後的干預。
2，接下來，用戶允許Dalvik對該應用使用「解釋」，「JIT」的方法，從而該應用程序得以執行。
3，用戶隨時可以對該應用作出任意不違反版權的干預。
所以，在沒有另行規定的前提下，用戶總是可以自行決定，通過給應用程序分配自定義的許可權；或是在應用程序調取內容，對象時予以阻斷。同時，用戶也需要自行承擔因不當操作產生的後果。
附錄：
1、 數字簽名
數字簽名是一種使用了公鑰加密領域的技術實現，用於鑒別數字信息的方法。一套數字簽名通常定義兩種互補的運算，一個用於簽名，另一個用於驗證。數字簽名可以輕易地驗證完整性（正確性），合法簽署的數字簽名具有不可否認性。 （摘錄自維基網路「數字簽名」條目，有修改）
2、 版權聲明
文章中引用的圖標，圖片或圖片的部分，以及部分文字的引用，僅出於合理使用的目的，可能是持有人版權所有的。
3、 一些行為的說明
不道德行為
應用程序在啟動時，或在主動告知以前，試圖索取、收集電話號碼、郵箱地址、位置信息等與個人身份直接關聯的內容。如果是與個人關聯，但不能直接聯繫到個人信息的IMEI等設備、SIM卡的串號，則稍微好一些。
附圖1，不道德的應用程序在啟動的第一時間就試圖獲取隱私信息
（新浪微博2.8），無論用戶是否綁定了手機，應用都會第一時間記錄當前手機的號碼
（UC瀏覽器，快拍二維碼），應用總是會不主動通知地記錄設備的位置信息
沒有實行主動通知的例子
附圖2 這個應用程序在第一次啟動時便開始收集位置信息，用戶需要切換六次屏幕才能看到有關位置信息的提示。這項提示還有意忽略應用程序本身就會記錄用戶位置信息，即便用戶並不使用需要位置信息的服務
主動通知的例子
附圖3 主動通知就是在第一屏的醒目處，或用醒目的對比色等強調方式進行通告