安卓源碼的類
㈠ 請問 Android.util.log 這個類在 android 源碼中哪個包呢
就在android.util這個包下面。在frameworks/base/core下面,可以搜索一下find ./frameworks/base -name Log.java
㈡ 用什麼工具打開安卓app源碼
android源代碼文件通過在Eclipse中打開就可以,前提是要把源碼導入到Eclipse中,然後ctrl+類 就可可以點擊查看。
㈢ 引用android 源碼device目錄下的類為什麼會顯示不存在
Eclipse只能查看API的注釋及說明,而且是必須與jar包關聯以後才能查看 jar包與docs關聯方式: 1. 打開Eclipse,隨便新建一個Android項目,在此項目目錄下面有個Android 4.4,點擊遍出現了android.jar。 2. 右鍵此包---->Properties,在彈出的窗口中,選擇 Java Source Attachment------>External Location------>External File, 然後選擇下載下來的source-19_r02.zip,便成功在Eclipse中綁定Android源代碼。 3. ctl+滑鼠左鍵 跳轉到源代碼 在想要查看源代碼的地方,ctl+滑鼠左鍵就可以跳轉到源代碼的地方。 Android Studio源代碼關聯方式: 1.打開菜單File ->Project Structure (或者按F4)。 2.在左邊列表中選擇Moles。 3.選擇工程,然後在第三個標簽頁頁找到Dependencies。 4.按「+」按鈕,在彈出窗口中選擇android-support-v4.jar所在文件夾(在SDK目錄下),然後確認即可
㈣ APP的源代碼是什麼意思(安卓的)
開源(Open Source,開放源碼)被非盈利軟體組織(美國的Open Source Initiative協會)注冊為認證標記,並對其進行了正式的定義,用於描述那些源碼可以被公眾使用的軟體,並且此軟體的使用、修改和發行也不受許可證的限制。
安卓的開源就是開放源代碼,安卓2.x的內核是linux2.6.方便軟體商開發,多數軟體可以免費,手機商不用買系統版權,降低成本和零售價.這些都是對用戶直接或間接的好處.
㈤ Android 反編譯之後的源代碼類名被混淆了,類名變為a-z毫無意義的名字,有什麼辦法可以找到原始的類名嗎
沒辦法 就是這樣 不然源代碼隨便改 就亂了
㈥ 安卓的系統源代碼是用什麼編程語言寫的有源代碼的拿來看看!
安卓系統是基於linux,bootload是匯編+C的結合,內核、底層驅動 是用c ,應用程序是java
㈦ Android源碼解析RPC系列(一)---Binder原理
看了幾天的Binder,決定有必要寫一篇博客,記錄一下學習成果,Binder是Android中比較綜合的一塊知識了,目前的理解只限於JAVA層。首先Binder是幹嘛用的?不用說,跨進程通信全靠它,操作系統的不同進程之間,數據不共享,對於每個進程來說,它都天真地以為自己獨享了整個系統,完全不知道其他進程的存在,進程之間需要通信需要某種系統機制才能完成,在Android整個系統架構中,採用了大量的C/S架構的思想,所以Binder的作用就顯得非常重要了,但是這種機制為什麼是Binder呢?在Linux中的RPC方式有管道,消息隊列,共享內存等,消息隊列和管道採用存儲-轉發方式,即數據先從發送方緩存區拷貝到內核開辟的緩存區中,然後再從內核緩存區拷貝到接收方緩存區,這樣就有兩次拷貝過程。共享內存不需要拷貝,但控制復雜,難以使用。Binder是個折中的方案,只需要拷貝一次就行了。其次Binder的安全性比較好,好在哪裡,在下還不是很清楚,基於安全性和傳輸的效率考慮,選擇了Binder。Binder的英文意思是粘結劑,Binder對象是一個可以跨進程引用的對象,它的實體位於一個進程中,這個進程一般是Server端,該對象提供了一套方法用以實現對服務的請求,而它的引用卻遍布於系統的各個進程(Client端)之中,這樣Client通過Binder的引用訪問Server,所以說,Binder就像膠水一樣,把系統各個進程粘結在一起了,廢話確實有點多。
為了從而保障了系統的安全和穩定,整個系統被劃分成內核空間和用戶空間
內核空間:獨立於普通的應用程序,可以訪問受保護的內存空間,有訪問底層硬體設備的所有許可權。
用戶空間:相對與內核空間,上層運用程序所運行的空間就是用戶空間,用戶空間訪問內核空間的唯一方式就是系統調用。一個4G的虛擬地址空間,其中3G是用戶空間,剩餘的1G是內核空間。如果一個用戶空間想與另外一個用戶空間進行通信,就需要內核模塊支持,這個運行在內核空間的,負責各個用戶進程通過Binder通信的內核模塊叫做Binder驅動,雖然叫做Binder驅動,但是和硬體並沒有什麼關系,只是實現方式和設備驅動程序是一樣的,提供了一些標准文件操作。
在寫AIDL的時候,一般情況下,我們有兩個進程,一個作為Server端提供某種服務,然後另外一個進程作為Client端,連接Server端之後,就 可以使用Server裡面定義的服務。這種思想是一種典型的C/S的思想。值得注意的是Android系統中的Binder自身也是C/S的架構,也有Server端與Client端。一個大的C/S架構中,也有一個小的C/S架構。
先籠統的說一下,在整個Binder框架中,由系列組件組成,分別是Client、Server、ServiceManager和Binder驅動程序,其中Client、Server和ServiceManager運行在用戶空間,Binder驅動程序運行內核空間。運行在用戶空間中的Client、Server和ServiceManager,是在三個不同進程中的,Server進程中中定義了服務提供給Client進程使用,並且Server中有一個Binder實體,但是Server中定義的服務並不能直接被Client使用,它需要向ServiceManager注冊,然後Client要用服務的時候,直接向ServiceManager要,ServiceManager返回一個Binder的替身(引用)給Client,這樣Client就可以調用Server中的服務了。
場景 :進程A要調用進程B裡面的一個draw方法處理圖片。
分析 :在這種場景下,進程A作為Client端,進程B做為Server端,但是A/B不在同一個進程中,怎麼來調用B進程的draw方法呢,首先進程B作為Server端創建了Binder實體,為其取一個字元形式,可讀易記的名字,並將這個Binder連同名字以數據包的形式通過Binder驅動發送給ServiceManager,也就是向ServiceManager注冊的過程,告訴ServiceManager,我是進程B,擁有圖像處理的功能,ServiceManager從數據包中取出名字和引用以一個注冊表的形式保留了Server進程的注冊信息。為什麼是以數據包的形式呢,因為這是兩個進程,直接傳遞對象是不行滴,只能是一些描述信息。現在Client端進程A聯系ServiceManager,說現在我需要進程B中圖像處理的功能,ServiceManager從注冊表中查到了這個Binder實體,但是呢,它並不是直接把這個Binder實體直接給Client,而是給了一個Binder實體的代理,或者說是引用,Client通過Binder的引用訪問Server。分析到現在,有個關鍵的問題需要說一下,ServiceManager是一個進程,Server是另一個進程,Server向ServiceManager注冊Binder必然會涉及進程間通信。當前實現的是進程間通信卻又要用到進程間通信,這就好象蛋可以孵出雞前提卻是要找只雞來孵蛋,確實是這樣的,ServiceManager中預先有了一個自己的Binder對象(實體),就是那隻雞,然後Server有個Binder對象的引用,就是那個蛋,Server需要通過這個Binder的引用來實現Binder的注冊。雞就一隻,蛋有很多,ServiceManager進程的Binder對象(實體)僅有一個,其他進程所擁有的全部都是它的代理。同樣一個Server端Binder實體也應該只有一個,對應所有Client端全部都是它的代理。
我們再次理解一下Binder是什麼?在Binder通信模型的四個角色裡面;他們的代表都是「Binder」,一個Binder對象就代表了所有,包括了Server,Client,ServiceManager,這樣,對於Binder通信的使用者而言,不用關心實現的細節。對Server來說,Binder指的是Binder實體,或者說是本地對象,對於Client來說,Binder指的是Binder代理對象,也就是Binder的引用。對於Binder驅動而言,在Binder對象進行跨進程傳遞的時候,Binder驅動會自動完成這兩種類型的轉換。
簡單的總結一下,通過上面一大段的分析,一個Server在使用的時候需要經歷三個階段
1、定義一個AIDL文件
Game.aidl
GameManager .aidl
2、定義遠端服務Service
在遠程服務中的onBind方法,實現AIDL介面的具體方法,並且返回Binder對象
3、本地創建連接對象
以上就是一個遠端服務的一般套路,如果是在兩個進程中,就可以進程通信了,現在我們分析一下,這個通信的流程。重點是GameManager這個編譯生成的類。
從類的關系來看,首先介面GameManager 繼承 IInterface ,IInterface是一個介面,在GameManager內部有一個內部類Stub,Stub繼承了Binder,(Binder實現了IBinder),並且實現了GameManager介面,在Stub中還有一個內部類Proxy,Proxy也實現了GameManager介面,一個整體的結構是這樣的
現在的問題是,Stub是什麼?Proxy又是什麼?在上面說了在Binder通信模型的四個角色裡面;他們的代表都是「Binder」,一個Binder對象就代表了所有,包括了Server,Clinet,ServiceManager,為了兩個進程的通信,系統給予的內核支持是Binder,在抽象一點的說,Binder是系統開辟的一塊內存空間,兩個進程往這塊空間裡面讀寫數據就行了,Stub從Binder中讀數據,Proxy向Binder中寫數據,達到進程間通信的目的。首先我們分析Stub。
Stub 類繼承了Binder ,說明了Stub有了跨進程傳輸的能力,實現了GameManager介面,說明它有了根據游戲ID查詢一個游戲的能力。我們在bind一個Service之後,在onServiceConnecttion的回調裡面,就是通過asInterface方法拿到一個遠程的service的。
asInterface調用queryLocalInterface。
mDescriptor,mOwner其實是Binder的成員變數,Stub繼承了Binder,在構造函數的時候,對著兩個變數賦的值。
如果客戶端和服務端是在一個進程中,那麼其實queryLocalInterface獲取的就是Stub對象,如果不在一個進程queryLocalInterface查詢的對象肯定為null,因為不同進程有不同虛擬機,肯定查不到mOwner對象的,所以這時候其實是返回的Proxy對象了。拿到Stub對象後,通常在onServiceConnected中,就把這個對象轉換成我們多定義AIDL介面。
比如我們這里會轉換成GameManager,有了GameManager對象,就可以調用後querryGameById方法了。如果是一個進程,那直接調用的是自己的querryGameById方法,如果不是一個進程,那調用了就是代理的querryGameById方法了。
看到其中關鍵的一行是
mRemote就是一個IBinder對象,相對於Stub,Proxy 是組合關系(HAS-A),內部有一個IBinder對象mRemote,Stub是繼承關系(IS-A),直接實現了IBinder介面。
transact是個native方法,最終還會回掉JAVA層的onTransact方法。
onTransact根據調用號(每個AIDL函數都有一個編號,在跨進程的時候,不會傳遞函數,而是傳遞編號指明調用哪個函數)調用相關函數;在這個例子裡面,調用了Binder本地對象的querryGameById方法;這個方法將結果返回給驅動,驅動喚醒掛起的Client進程裡面的線程並將結果返回。於是一次跨進程調用就完成了。
***Please accept mybest wishes for your happiness and success ! ***
㈧ Android 能正常運行但源碼包中很多類找不到該怎麼處理
查看源碼的時候,有些源碼沒有,這個一般都是你本地的SDK沒有下載對應版本代碼,所以找不到,不過這個不影響開發,因為android系統裡面已經包含了這些類,所以運行不會出錯。
㈨ 如何在Android源碼中加入Java層系統服務
1. 在android/app/目錄下創建介面文件IServiceTest.aidl
package android.app;
oneway interface IServiceTest
{
void show();
}
2. 在Android.mk文件中的變數LOCAL_SRC_FILES中加入core/java/android/app/IServiceTest.aidl
如果要在sdk中發布這個服務就在變數aidl_files中加入一樣的路徑。
3. 通過aidl編譯器編譯IServiceTest.aidl,會生成一個IServiceTest.java文件。
4. 創建服務類ServiceTestSerice
class ServiceTestSerice extends IServiceTest.Stub{
private static final String TAG = 「ServiceTestSerice」;
Context mContext;
public ServiceTestSerice(Context context){
mContext = context;
}
public void show() throws RemoteException {
System.out.println(「My ServiceTestSerice」);
}
}
.5. 注冊服務
Java系統服務在ServerThread類的run()方法中生成並注冊到android平台,生成ServiceTestSerice實例對象,通過ServiceManager的addService方法將服務注冊到系統中。
try{
serviceTestSerice = new ServiceTestSerice(context);
ServiceManager.addService(Context.SERVICE_TEST, serviceTestSerice);
} catch (Throwable t) {
}
ServiceTestSerice serviceTestSerice;
以上代碼在ServerThread類的run()方法中。
在Context類中加入:
public static final StringSERVICE_TEST = 「servicetest」
ServiceTestManager sServiceTestManager;
6. 使用系統服務
編寫一個ServiceTestManager類,為包裝類。
public class ServiceTestManager{
private final IServiceTest mService;
ServiceTestManager(IServiceTest service){
mService = service;
}
public void test(){
try{
mService. show()
} catch (RemoteException ex){
}
}
}
7 提供應用層開發介面
在ContextImpl類中的getSystemService()方法中加入如下代碼:
else if (SERVICE_TEST.equals(name)){
return getServiceTestManager();
}
private ServiceTestManager getServiceTestManager(){
synchronized(sSync) {
if (sServiceTestManager == null){
IBinder b = ServiceManager.getService(SERVICE_TEST);
IServiceTest service = IServiceTest.Stub.asInterface(b);
sServiceTestManager = new ServiceTestManager(service);
}
}
調用過程如下:
ServiceTestManager manager= (ServiceTestManager) getSystemService(Context. SERVICE_TEST);
manager.show();
8. 測試
make
make update-api 更新current.xml文件
生成system.imz文件,放到<ANDROID_SDK>/platform/android-20/images/目錄下,
adb shell
service list