2014-11-05 12 views
11

Android wprowadził @SystemApi w swoim kodzie źródłowym SDK niedawno. Wygląda to tak samo jak przed adnotacją @hide, ponieważ zostały one również usunięte z klas słoików SDK.Jakie jest znaczenie nowej adnotacji @SystemApi, jakąkolwiek różnicę od @hide?

Czy jest możliwe, że aplikacja może je wywoływać w inny sposób niż stare interfejsy API @hide.

/** 
* Indicates an API is exposed for use by bundled system applications. 
* <p> 
* These APIs are not guaranteed to remain consistent release-to-release, 
* and are not for use by apps linking against the Android SDK. 
* </p><p> 
* This annotation should only appear on API that is already marked <pre>@hide</pre>. 
* </p> 
* 
* @hide 
*/ 

Odpowiedz

0

Methods opatrzone @SystemApi są podzbiorem tych z @hide. To najwyraźniej wskaźnik dla wewnętrznych zespołów (być może także partnerów), że te metody są rzeczywistymi API, chociaż nie dla publicznych deweloperów.

W rezultacie metody @SystemApi będą bardziej stabilne niż metody @hide, które mogą zostać zmienione w dowolnym momencie w przyszłości bez uwzględnienia zgodności, a także każdy producent OEM może je zmienić we własnym zakresie.

Jeśli próbujesz wywołać wewnętrzne interfejsy API za pomocą refleksji, zawsze preferuj metody @SystemApi, aby uzyskać lepszą kompatybilność w przyszłości.

15

@SystemApi, @PrivateApi i @hide

Według this commit, @SystemApi jest zmiana nazwy starego @PrivateApi. Interfejsy API oznaczone jako @hide niekoniecznie są @SystemApi, ale @SystemApi wymaga @hide.

Aby uzyskać więcej informacji o @hide, adnotacja javadoc, this post daje dobrą odpowiedź.

Bazując na własnych doświadczeniach, jeden (aplikacja non-System) można nadal uzyskać dostęp @hide API i pól użyciu odbicia Java podobne (z this post):

WifiManager manager = (WifiManager) getSystemService(Context.WIFI_SERVICE); 

WifiConfiguration config = new WifiConfiguration(); 
config.SSID = "AccessPointSSID"; 

Method method = manager.getClass().getMethod("setWifiApEnabled", WifiConfiguration.class, boolean.class); 
method.invoke(manager, config, true); 

Ale próby dostępu @SystemApi rzeczy przy użyciu odbicia Java jest niemożliwe (Poniższy kod wywoła invocationTargetException):

WifiManager manager = (WifiManager) getSystemService(Context.WIFI_SERVICE); 

Method method = manager.getClass().getMethod("getPrivilegedConfiguredNetworks"); 
List<WifiConfiguration> configs = (List<WifiConfiguration>)method.invoke(manager); 

P.S.

W WifiManager java code, API setWifiApEnabled i getPrivilegedConfiguredNetworks są zdefiniowane jako:

/** 
* Start AccessPoint mode with the specified 
* configuration. If the radio is already running in 
* AP mode, update the new configuration 
* Note that starting in access point mode disables station 
* mode operation 
* @param wifiConfig SSID, security and channel details as 
*  part of WifiConfiguration 
* @return {@code true} if the operation succeeds, {@code false} otherwise 
* 
* @hide Dont open up yet 
*/ 
public boolean setWifiApEnabled(WifiConfiguration wifiConfig, boolean enabled) { 
    try { 
     mService.setWifiApEnabled(wifiConfig, enabled); 
     return true; 
    } catch (RemoteException e) { 
     return false; 
    } 
} 

i

/** @hide */ 
@SystemApi 
public List<WifiConfiguration> getPrivilegedConfiguredNetworks() { 
    try { 
     return mService.getPrivilegedConfiguredNetworks(); 
    } catch (RemoteException e) { 
     return null; 
    } 
} 
+0

Dzięki za wyjaśnienie! W moich testach większość interfejsów API z adnotacjami '@ SystemApi' i' @ hide' (poprzednio opatrzonych adnotacją "@ hide") jest nadal dostępna poprzez odbicie. Jaka jest szczegółowa wiadomość 'InvocationTargetException' w twoim przypadku? –

+0

Zrobiłem eksperyment na moim Nexusie 5 z Androidem 5.0. @ Oasis-feng Przypuszczam, że zachowanie '@ SystemApi' jest związane z wersją? –

+0

Testowałem również na Nexusie 5 z Androidem 5.0.2. Może różni się od API do API. Czy możesz wkleić szczegółową wiadomość z InvocationTargetException? –

Powiązane problemy