Gli "stub" qui sono lo stub dell'API framework generato eseguendo lo strumento javadoc.
Nella maggior parte dei casi, quando si parla di file stub in Android, si intende il file java generato dallo strumento aidl. Per esempio vedi How to generate stub in android? - Stack Overflow
In particolare, il sistema di generazione di Android contiene un makefile chiamato droiddoc.mk che può essere usato per generare la documentazione, stub API Java e file XML API, che in realtà chiama javadoc.
droiddoc.mk è sotto build/core. In build/core/config.mk c'è una variabile denominata BUILD_DROIDDOC per semplificare l'inclusione dello droiddoc.mk.
sguardo al droiddoc.mk, chiama javadoc:
javadoc \
\@$(PRIVATE_SRC_LIST_FILE) \
-J-Xmx1280m \
$(PRIVATE_PROFILING_OPTIONS) \
-quiet \
-doclet com.google.doclava.Doclava \
-docletpath $(PRIVATE_DOCLETPATH) \
-templatedir $(PRIVATE_CUSTOM_TEMPLATE_DIR) \
$(PRIVATE_DROIDDOC_HTML_DIR) \
$(addprefix -bootclasspath ,$(PRIVATE_BOOTCLASSPATH)) \
$(addprefix -classpath ,$(PRIVATE_CLASSPATH)) \
-sourcepath $(PRIVATE_SOURCE_PATH)$(addprefix :,$(PRIVATE_CLASSPATH)) \
-d $(PRIVATE_OUT_DIR) \
$(PRIVATE_CURRENT_BUILD) $(PRIVATE_CURRENT_TIME) \
$(PRIVATE_DROIDDOC_OPTIONS) \
&& touch -f [email protected]
Non c'è nulla di destra stub? Non ti preoccupare, notare che c'è una variabile PRIVATE_DROIDDOC_OPTIONS e
PRIVATE_DROIDDOC_OPTIONS := $(LOCAL_DROIDDOC_OPTIONS)
Molti file Android.mk in AOSP, ad esempio, la framework/base/Android.mk, contiene il include $(BUILD_DROIDDOC) per generare documenti. In framework/base/Android.mk, c'è un pezzo di codice:
LOCAL_DROIDDOC_OPTIONS:=\
$(framework_docs_LOCAL_DROIDDOC_OPTIONS) \
-stubs $(TARGET_OUT_COMMON_INTERMEDIATES)/JAVA_LIBRARIES/android_stubs_current_intermediates/src \
-api $(INTERNAL_PLATFORM_API_FILE) \
-nodocs
LOCAL_DROIDDOC_CUSTOM_TEMPLATE_DIR:=build/tools/droiddoc/templates-sdk
LOCAL_UNINSTALLABLE_MODULE := true
include $(BUILD_DROIDDOC)
Il LOCAL_DROIDDOC_OPTIONS contiene un'opzione -stubs. E infine verrà inserito nel comando javadoc utilizzato da droiddoc.mk.
Tuttavia, potremmo notare che javadoc non contiene alcuna opzione come -stubs. La chiave è che è possibile personalizzare il contenuto e il formato dell'output dello strumento Javadoc utilizzando doclet. Lo strumento Javadoc ha un doclet predefinito "incorporato", chiamato doclet standard, che genera documentazione API in formato HTML. È possibile modificare o sottoclasse il doclet standard o scrivere il proprio doclet per generare HTML, XML, MIF, RTF o qualsiasi formato di output desiderato.
Possiamo usare l'opzione -doclet per specificare il nostro doclet personalizzato. E il comando javadoc in droiddoc.mk usa lo -doclet com.google.doclava.Doclava. Quel doclet riceve l'opzione -stubs.
Guardate l'attuazione Doclava sotto external/doclava/src/com/google/doclava/Doclava.java
else if (a[0].equals("-stubs")) {
stubsDir = a[1];
} else if (a[0].equals("-stubpackages")) {
stubPackages = new HashSet<String>();
for (String pkg : a[1].split(":")) {
stubPackages.add(pkg);
}
}
Riceve l'opzione -stubs. Ed ecco come processa lo stubsDir.
// Stubs
if (stubsDir != null || apiFile != null || proguardFile != null) {
Stubs.writeStubsAndApi(stubsDir, apiFile, proguardFile, stubPackages);
}
e tracciare l'attuazione del Stubs.writeStubsAndApi, si può capire perché il contenuto dei file stub sono così.
È anche possibile scrivere i propri file java e generare i propri stub come i casi di test con build/tools/droiddoc/test.
http://stackoverflow.com/questions/1264530/how-to-generate-stub-in-android?rq=1 potrebbero avere alcune risposte, non so se non ne so molto. –
La mia domanda è diversa. Per stub, in particolare intendo i file .java che sono prodotti nella suddetta directory come parte del processo di build di Android. –