Automatic and manual target modes
By default, a run configuration uses the automatic target mode in order to -select -an AVD. In this mode, ADT will select an AVD for the application in the following manner:
+select an AVD. In this mode, ADT will select an AVD for the application in the following manner:- If there's a device or emulator already running and its AVD configuration
@@ -349,6 +355,381 @@ and what it means to you as an Android application developer. The document also
a guide to exporting and signing your application with the ADT's Export Wizard.
+
Working with Library Projects
+ +++ +++Library project example code
+ +The SDK includes an example application called TicTacToeMain that shows how a +dependent application can use code and resources from an Android Library +project. The TicTacToeMain application uses code and resources from an example +library project called TicTacToeLib. + +
To download the sample applications and run them as +projects in your environment, use the Android SDK and AVD Manager to +download the "Samples for SDK API 8" component into your SDK.
+ +For more information and to browse the code of the +samples, see the TicTacToeMain +application.
+An Android library project is a development project that holds +shared Android source code and resources. Other Android application projects can +reference the library project and, at build time, include its compiled sources +in their
+ +.apkfiles. Multiple application projects can reference +the same library project and any single application project can reference +multiple library projects.If you have source code and resources that are common to multiple application +projects, you can move them to a library project so that it is easier to +maintain across applications and versions. Here are some common scenarios in +which you could make use of library projects:
+ +-
+
- If you are developing multiple related applications that use some of the +same components, you move the redundant components out of their respective +application projects and create a single, reuseable set of the same components +in a library project. +
- If you are creating an application that exists in both free and paid +versions. You move the part of the application that is common to both versions +into a library project. The two dependent projects, with their different package +names, will reference the library project and provide only the difference +between the two application versions. +
Structurally, a library project is similar to a standard Android application +project. For example, it includes a manifest file at the project root, as well +as
+ +src/,res/and similar directories. The project can +contain the same types of source code and resources as a standard +Android project, stored in the same way. For example, source code in the library +project can access its own resources through itsRclass.However, a library project differs from an standard Android application +project in that you cannot compile it directly to its own
+ +.apkor +run it on the Android platform. Similarly, you cannot export the library project +to a self-contained JAR file, as you would do for a true library. Instead, you +must compile the library indirectly, by referencing the library from a dependent +application's build path, then building that application.When you build an application that depends on a library project, the SDK +tools compile the library and merge its sources with those in the main project, +then use the result to generate the
+ +.apk. In cases where a resource +ID is defined in both the application and the library, the tools ensure that the +resource declared in the application gets priority and that the resource in the +library project is not compiled into the application.apk. This +gives your application the flexibility to either use or redefine any resource +behaviors or values that are defined in any library.To organize your code further, your application can add references to +multiple library projects, then specify the relative priority of the resources +in each library. This lets you build up the resources actually used in your +application in a cumulative manner. When two libraries referenced from an +application define the same resource ID, the tools select the resource from the +library with higher priority and discard the other.
+ +ADT lets you add references to library projects and set their relative +priority from the application project's Properties. As shown in Figure 2, +below, once you've added a reference to a library project, you can use the +Up and Down controls to change the ordering, +with the library listed at the top getting the higher priority. At build time, +the libraries are merged with the application one at a time, starting from the +lowest priority to the highest.
+ +Note that a library project cannot itself reference another library project +and that, at build time, library projects are not merged with each +other before being merged with the application. However, note that a library can +import an external library (JAR) in the normal way.
+ +The sections below describe how to use ADT to set up and manage library your +projects. Once you've set up your library projects and moved code into them, you +can import library classes and resources to your application in the normal way. +
+ + +Development requirements
+ +Android library projects are a build-time construct, so you can use them to +build a final application
+ +.apkthat targets any API level and is +compiled against any version of the Android library.However, to use library projects, you need to update your development +environment to use the latest tools and platforms, since older releases of the +tools and platforms do not support building with library projects. Specifically, +you need to download and install the versions listed below:
+ +Table 1. Minimum versions of SDK tools +and plaforms on which you can develop library projects.
+ ++
+ ++ +Component +Minimum Version ++ +SDK Tools +r6 (or higher) +Android 2.2 platform r1 (or higher) Android 2.1 platform r2 (or higher) Android 2.0.1 platform not supported Android 2.0 platform not supported Android 1.6 platform r3 (or higher) Android 1.5 platform r4 (or higher) ADT Plugin 0.9.7 (or higher) You can download the tools and platforms using the Android SDK and AVD +Manager, as described in Adding SDK +Components. To install or update ADT, use the Eclipse Updater as described +in ADT Plugin for Eclipse.
+ + +Setting up a library project
+ +A library project is a standard Android project, so you can create a new one in the +same way as you would a new application project. Specifically, you can use +the New Project Wizard, as described in Creating an +Android Project, above.
+ +When you are creating the library project, you can select any application +name, package, and set other fields as needed, as shown in the diagram below. +Click Finish to create the project in the workspace.
+ +Next, set the project's Properties to indicate that it is a library project:
+ +-
+
- In the Package Explorer, right-click the library project +and select Properties. +
- In the Properties window, select the "Android" properties +group at left and locate the Library properties at right. +
- Select the "is Library" checkbox and click Apply. +
- Click OK to close the Properties window. +
The new project is now marked as a library project. You can begin moving +source code and resources into it, as described in the sections below.
+ +You can also convert an existing application project into a library. To do +so, simply open the Properties for the project and select the "is Library" +checkbox. Other application projects can now reference the existing project as a +library project.
+ +
+Figure 1. +Marking a project as an Android library project.
+ +Creating the manifest file
+ +A library project's manifest file must declare all of the shared components +that it includes, just as would a standard Android application. For more +information, see the documentation for AndroidManifest.xml.
+ +For example, the TicTacToeLib +example library project declares the Activity
+ +GameActivity:<manifest> + ... + <application> + ... + <activity android:name="GameActivity" /> + ... + </application> + ... +</manifest>
+ + +Referencing a library project from an application
+ +If you are developing an application and want to include the shared code or +resources from a library project, you can do so easily by adding a reference to +the library project in the application project's Properties.
+ +To add a reference to a library project, follow these steps:
+ +-
+
- In the Package Explorer, right-click the dependent project +and select Properties. +
- In the Properties window, select the "Android" properties group +at left and locate the Library properties at right. +
- Click Add to open the Project Selection +dialog. +
- From the list of available library projects, select a project and click +OK. +
- When the dialog closes, click Apply in the +Properties window. +
- Click OK to close the Properties window. +
As soon as the Properties dialog closes, Eclipse rebuilds the project, +including the contents of the library project.
+ +The figure below shows the Properties dialog that lets you add library +references and move them up and down in priority.
+ +
+Figure 2. +Adding a reference to a library project in the properties of an application project.
+ +If you are adding references to multiple libraries, note that you can set +their relative priority (and merge order) by selecting a library and using the +Up and Down controls. The tools merge the +referenced libraries with your application starting from lowest priority (bottom +of the list) to highest (top of the list). If more than one library defines the +same resource ID, the tools select the resource from the library with higher +priority. The application itself has highest priority and its resources are +always used in preference to identical resource IDs defined in libraries.
+ +Declaring library components in the the manifest file
+ +In the manifest file of the application project, you must add declarations +of all components that the application will use that are imported from a library +project. For example, you must declare any
+ +<activity>, +<service>,<receiver>, +<provider>, and so on, as well as +<permission>,<uses-library>, and similar +elements.Declarations should reference the library components by their fully-qualified +package names, where appropriate.
+ +For example, the TicTacToeMain +example application declares the library Activity
+ +GameActivity+like this:<manifest> + ... + <application> + ... + <activity android:name="com.example.android.tictactoe.library.GameActivity" /> + ... + </application> + ... +</manifest>
+ +For more information about the manifest file, see the documentation for AndroidManifest.xml.
+ + +Development considerations
+ +As you develop your library project and dependent applications, keep the +points listed below in mind.
+ +Resource conflicts
+ +Since the tools merge the resources of a library project with those of a +dependent application project, a given resource ID might be defined in both +projects. In this case, the tools select the resource from the application, or +the library with highest priority, and discard the other resource. As you +develop your applications, be aware that common resource IDs are likely to be +defined in more than one project and will be merged, with the resource from the +application or highest-priority library taking precedence.
+ +Using prefixes to avoid resource conflicts
+ +To avoid resource conflicts for common resource IDs, consider using a prefix +or other consistent naming scheme that is unique to the project (or is unique +across all projects).
+ +No export of library project to JAR
+ +A library cannot be distributed as a binary file (such as a jar file). This +is because the library project is compiled by the main project to use the +correct resource IDs.
+ +One library project cannot reference another
+ +A library cannot depend on another library.
+ +A library project can include a JAR library
+ +You can develop a library project that itself includes a JAR library, however +you need to manually edit the dependent application project's build path and add +a path to the JAR file.
+ +A library project can depend on an external JAR library
+ +You can develop a library project that depends on an external library (for +example, the Maps external library). In this case, the dependent application +must build against a target that includes the external library (for example, the +Google APIs Add-On). Note also that both the library project and the dependent +application must declare the external library their manifest files, in a
+ +<uses-library>+element.Library project can not include AIDL files
+ +The tools do not support the use of AIDL files in a library project. +Any AIDL files used by an application must be stored in the application project +itself.
+ +Library project can not include raw assets
+ +The tools do not support the use of raw asset files in a library project. +Any asset resources used by an application must be stored in the +
+ +assets/directory of the application project +itself.Targeting different Android platform versions in library project and +application project
+ +A library is compiled as part of the dependent application project, so the +API used in the library project must be compatible with the version of the +Android library used to compile the application project. In general, the library +project should use an API level +that is the same as — or lower than — that used by the application. +If the library project uses an API level that is higher than that of the +application, the application project will fail to compile. It is perfectly +acceptable to have a library that uses the Android 1.5 API (API level 3) and +that is used in an Android 1.6 (API level 4) or Android 2.1 (API level 7) +project, for instance.
+ +No restriction on library package name
+ +There is no requirement for the package name of a library to be the same as +that of applications that use it.
+ +Multiple R classes in gen/ folder of application project
+ +When you build the dependent application project, the code of any libraries +is compiled and merged to the application project. Each library has its own +
+ +Rclass, named according to the library's package name. The +Rclass generated from the resources of the main project and of the +library is created in all the packages that are needed including the main +project’s package and the libraries’ packages.Testing a library project
+ +There are two recommended ways of setting up testing on code and resources in +a library project:
+ +-
+
- You can set up a test project +that instruments an application project that depends on the library project. You +can then add tests to the project for library-specific features. +
- You can set up a set up a standard application project that depends on the +library and put the instrumentation in that project. This lets you create a +self-contained project that contains both the tests/instrumentations and the +code to test. +
Library project storage location
+ +There are no specific requirements on where you should store a library +project, relative to a dependent application project, as long as the application +project can reference the library project by a relative link. You can place the +library project What is important is that the main project can reference the +library project through a relative link.
+ +Eclipse Tips
Executing arbitrary Java expressions in Eclipse
diff --git a/docs/html/guide/developing/other-ide.jd b/docs/html/guide/developing/other-ide.jd index 76b2d9ff8b0a8..e8a6fb6494f82 100644 --- a/docs/html/guide/developing/other-ide.jd +++ b/docs/html/guide/developing/other-ide.jd @@ -20,6 +20,15 @@ page.title=Developing In Other IDEs - Running on a device
tools/ directory of your SDK and run:
android create project \
--target <target_ID> \
--name <your_project_name> \
---path /path/to/your/project \
+--path path/to/your/project \
--activity <your_activity_name> \
--package <your_package_namespace>
@@ -350,7 +359,7 @@ root of the project directory) and add entries for {@code key.store} and {@code
For example:
-key.store=/path/to/my.keystore +key.store=path/to/my.keystore key.alias=mykeystore@@ -458,7 +467,7 @@ emulator: directory after you build your application.
If there is more than one emulator running, you must specify the emulator upon which to
install the application, by its serial number, with the -s option. For example:
adb -s emulator-5554 install /path/to/your/app.apk+
adb -s emulator-5554 install path/to/your/app.apk
To see a list of available device serial numbers, execute {@code adb devices}.
@@ -499,12 +508,10 @@ Development for more information.Once your device is set up and connected via USB, navigate to your
SDK's tools/ directory and install the .apk on the device:
-
adb -d install /path/to/your/app.apk+
adb -d install path/to/your/app.apk
The {@code -d} flag specifies that you want to use the attached device (in case you also have an emulator running).
- -For more information on the tools used above, please see the following documents:
- android Tool @@ -512,6 +519,409 @@ have an emulator running).
- Android Debug Bridge (ADB)
Working with Library Projects
+ +Library project example code
+ +The SDK includes an example application called TicTacToeMain that shows how a +dependent application can use code and resources from an Android Library +project. The TicTacToeMain application uses code and resources from an example +library project called TicTacToeLib. + +
To download the sample applications and run them as +projects in your environment, use the Android SDK and AVD Manager to +download the "Samples for SDK API 8" component into your SDK.
+ +For more information and to browse the code of the +samples, see the TicTacToeMain +application.
+An Android library project is a development project that holds
+shared Android source code and resources. Other Android application projects can
+reference the library project and, at build time, include its compiled sources
+in their .apk files. Multiple application projects can reference
+the same library project and any single application project can reference
+multiple library projects.
If you have source code and resources that are common to multiple application +projects, you can move them to a library project so that it is easier to +maintain across applications and versions. Here are some common scenarios in +which you could make use of library projects:
+ +-
+
- If you are developing multiple related applications that use some of the +same components, you move the redundant components out of their respective +application projects and create a single, reuseable set of the same components +in a library project. +
- If you are creating an application that exists in both free and paid +versions. You move the part of the application that is common to both versions +into a library project. The two dependent projects, with their different package +names, will reference the library project and provide only the difference +between the two application versions. +
Structurally, a library project is similar to a standard Android application
+project. For example, it includes a manifest file at the project root, as well
+as src/, res/ and similar directories. The project can
+contain the same types of source code and resources as a standard
+Android project, stored in the same way. For example, source code in the library
+project can access its own resources through its R class.
However, a library project differs from an standard Android application
+project in that you cannot compile it directly to its own .apk or
+run it on the Android platform. Similarly, you cannot export the library project
+to a self-contained JAR file, as you would do for a true library. Instead, you
+must compile the library indirectly, by referencing the library from a dependent
+application's build path, then building that application.
When you build an application that depends on a library project, the SDK
+tools compile the library and merge its sources with those in the main project,
+then use the result to generate the .apk. In cases where a resource
+ID is defined in both the application and the library, the tools ensure that the
+resource declared in the application gets priority and that the resource in the
+library project is not compiled into the application .apk. This
+gives your application the flexibility to either use or redefine any resource
+behaviors or values that are defined in any library.
To organize your code further, your application can add references to +multiple library projects, then specify the relative priority of the resources +in each library. This lets you build up the resources actually used in your +application in a cumulative manner. When two libraries referenced from an +application define the same resource ID, the tools select the resource from the +library with higher priority and discard the other. + +
Once you've have added references, the tools let you set their relative +priority by editing the application project's build properties. At build time, +the tools merge the libraries with the application one at a time, starting from +the lowest priority to the highest.
+ +Note that a library project cannot itself reference another library project +and that, at build time, library projects are not merged with each +other before being merged with the application. However, note that a library can +import an external library (JAR) in the normal way.
+ +The sections below describe how to use ADT to set up and manage library your +projects. Once you've set up your library projects and moved code into them, you +can import library classes and resources to your application in the normal way. +
+ + +Development requirements
+ +Android library projects are a build-time construct, so you can use them to
+build a final application .apk that targets any API level and is
+compiled against any version of the Android library.
However, to use library projects, you need to update your development +environment to use the latest tools and platforms, since older releases of the +tools and platforms do not support building with library projects. Specifically, +you need to download and install the versions listed below:
+ +Table 1. Minimum versions of SDK tools +and plaforms on which you can develop library projects.
+ +| Component | +Minimum Version | +
|---|---|
| SDK Tools | +r6 (or higher) | +
| Android 2.2 platform | r1 (or higher) |
| Android 2.1 platform | r2 (or higher) |
| Android 2.0.1 platform | not supported |
| Android 2.0 platform | not supported |
| Android 1.6 platform | r3 (or higher) |
| Android 1.5 platform | r4 (or higher) |
| ADT Plugin | 0.9.7 (or higher) |
You can download the tools and platforms using the Android SDK and AVD +Manager, as described in Adding SDK +Components.
+ + +Setting up a new library project
+ +A library project is a standard Android project, so you can create a new one in the
+same way as you would a new application project. Specifically, you can use
+the android tool to generate a new library project with all of the
+necessary files and folders.
Creating a library project
+ +To create a new library project, navigate to the <sdk>/tools/ directory
+and use this command:
+android create lib-project --name <your_project_name> \ +--target <target_ID> \ +--path path/to/your/project \ +--package <your_library_package_namespace> ++ +
The create lib-project command creates a standard project
+structure that includes preset property that indicates to the build system that
+the project is a library. It does this by adding this line to the project's
+default.properties file:
android.library=true+ +
Once the command completes, the library project is created and you can begin moving +source code and resources into it, as described in the sections below.
+ +If you want to convert an existing application project to a library project,
+so that other applications can use it, you can do so by adding a the
+android.library=true property to the application's
+default.properties file.
Creating the manifest file
+ +A library project's manifest file must declare all of the shared components +that it includes, just as would a standard Android application. For more +information, see the documentation for AndroidManifest.xml.
+ +For example, the TicTacToeLib
+example library project declares the Activity GameActivity:
<manifest> + ... + <application> + ... + <activity android:name="GameActivity" /> + ... + </application> + ... +</manifest>+ +
Updating a library project
+ +If you want to update the build properties (build target, location) of the +library project, use this command:
+ ++android update lib-project \ +--target <target_ID> \ +--path path/to/your/project ++ + +
Referencing a library project from an application
+ +If you are developing an application and want to include the shared code or +resources from a library project, you can do so easily by adding a reference to +the library project in the application project's build properties.
+ +To add a reference to a library project, navigate to the <sdk>/tools/ directory
+and use this command:
+android update lib-project \ +--target <target_ID> \ +--path path/to/your/project +--library path/to/library_projectA ++ +
This command updates the application project's build properties to include a
+reference to the library project. Specifically, it adds an
+android.library.reference.n property to the project's
+default.properties file. For example:
+android.library.reference.1=path/to/library_projectA ++ +
If you are adding references to multiple libraries, note that you can set
+their relative priority (and merge order) by manually editing the
+default.properties file and adjusting the each reference's
+.n index as appropriate. For example, assume these
+references:
+android.library.reference.1=path/to/library_projectA +android.library.reference.2=path/to/library_projectB +android.library.reference.3=path/to/library_projectC ++ +
You can reorder the references to give highest priority to
+library_projectC in this way:
+android.library.reference.2=path/to/library_projectA +android.library.reference.3=path/to/library_projectB +android.library.reference.1=path/to/library_projectC ++ +
Note that the .n index in the references
+must begin at "1" and increase uniformly without "holes". References
+appearing in the index after a hole are ignored.
At build time, the libraries are merged with the application one at a time, +starting from the lowest priority to the highest. Note that a library cannot +itself reference another library and that, at build time, libraries are not +merged with each other before being merged with the application.
+ + +Declaring library components in the the manifest file
+ +In the manifest file of the application project, you must add declarations
+of all components that the application will use that are imported from a library
+project. For example, you must declare any <activity>,
+<service>, <receiver>,
+<provider>, and so on, as well as
+<permission>, <uses-library>, and similar
+elements.
Declarations should reference the library components by their fully-qualified +package names, where appropriate.
+ +For example, the
+TicTacToeMain
+example application declares the library Activity GameActivity
+like this:
<manifest> + ... + <application> + ... + <activity android:name="com.example.android.tictactoe.library.GameActivity" /> + ... + </application> + ... +</manifest>+ +
For more information about the manifest file, see the documentation for AndroidManifest.xml.
+ +Building a dependent application
+ +To build an application project that depends on one or more library projects, +you can use the standard Ant build commands and compile modes, as described in +Building Your Application, earlier in this document. The +tools compile and merge all libraries referenced by the application as part +of compiling the dependent application project. No additional commands or steps +are necessary.
+ +Development considerations
+ +As you develop your library project and dependent applications, keep the +points listed below in mind.
+ +Resource conflicts
+ +Since the tools merge the resources of a library project with those of a +dependent application project, a given resource ID might be defined in both +projects. In this case, the tools select the resource from the application, or +the library with highest priority, and discard the other resource. As you +develop your applications, be aware that common resource IDs are likely to be +defined in more than one project and will be merged, with the resource from the +application or highest-priority library taking precedence.
+ +Using prefixes to avoid resource conflicts
+ +To avoid resource conflicts for common resource IDs, consider using a prefix +or other consistent naming scheme that is unique to the project (or is unique +across all projects).
+ +No export of library project to JAR
+ +A library cannot be distributed as a binary file (such as a jar file). This +is because the library project is compiled by the main project to use the +correct resource IDs.
+ +One library project cannot reference another
+ +A library cannot depend on another library.
+ +A library project can include a JAR library
+ +You can develop a library project that itself includes a JAR library. When
+you build the dependent application project, the tools automatically locate and
+include the library in the application .apk.
A library project can depend on an external JAR library
+ +You can develop a library project that depends on an external library (for
+example, the Maps external library). In this case, the dependent application
+must build against a target that includes the external library (for example, the
+Google APIs Add-On). Note also that both the library project and the dependent
+application must declare the external library their manifest files, in a <uses-library>
+element.
Library project cannot include AIDL files
+ +The tools do not support the use of AIDL files in a library project. +Any AIDL files used by an application must be stored in the application project +itself.
+ +Library project cannot include raw assets
+ +The tools do not support the use of raw asset files in a library project.
+Any asset resources used by an application must be stored in the
+assets/ directory of the application project
+itself.
Targeting different Android platform versions in library project and +application project
+ +A library is compiled as part of the dependent application project, so the +API used in the library project must be compatible with the version of the +Android library used to compile the application project. In general, the library +project should use an API level +that is the same as — or lower than — that used by the application. +If the library project uses an API level that is higher than that of the +application, the application project will fail to compile. It is perfectly +acceptable to have a library that uses the Android 1.5 API (API level 3) and +that is used in an Android 1.6 (API level 4) or Android 2.1 (API level 7) +project, for instance.
+ +No restriction on library package name
+ +There is no requirement for the package name of a library to be the same as +that of applications that use it.
+ +Multiple R classes in gen/ folder of application project
+ +When you build the dependent application project, the code of any libraries
+is compiled and merged to the application project. Each library has its own
+R class, named according to the library's package name. The
+R class generated from the resources of the main project and of the
+library is created in all the packages that are needed including the main
+project’s package and the libraries’ packages.
Testing a library project
+ +There are two recommended ways of setting up testing on code and resources in +a library project:
+ +-
+
- You can set up a test project +that instruments an application project that depends on the library project. You +can then add tests to the project for library-specific features. +
- You can set up a set up a standard application project that depends on the +library and put the instrumentation in that project. This lets you create a +self-contained project that contains both the tests/instrumentations and the +code to test. +
Library project storage location
+ +There are no specific requirements on where you should store a library +project, relative to a dependent application project, as long as the application +project can reference the library project by a relative link. You can place the +library project What is important is that the main project can reference the +library project through a relative link.
Attaching a Debugger to Your Application
diff --git a/docs/html/guide/practices/screens_support.jd b/docs/html/guide/practices/screens_support.jd index 1e254f0b9ea7f..45e3e49c52972 100644 --- a/docs/html/guide/practices/screens_support.jd +++ b/docs/html/guide/practices/screens_support.jd @@ -35,7 +35,7 @@ page.title=Supporting Multiple Screens @@ -279,16 +279,16 @@ href="{@docRoot}guide/resources/dashboard/screen-densities.html">Screen DensitieUsing the alternate resources framework
+Using the alternative resources framework
The platform's support for loading screen size- and density-specific -resources at run time is based on the alternate resources framework. +resources at run time is based on the alternative resources framework.
If you want to use size- or density-specific layouts or drawables in your application and you are not familiar with resource qualifiers or how the platform uses them, please read - -Alternate Resources. + +Alternative Resources.
For more information about how to use resource qualifiers or how the platform selects them, please read - -Alternate Resources.
+ +Alternative Resources.Best practices for Screen Independence
@@ -1023,8 +1023,8 @@ scaling.v<api-level>
diff --git a/docs/html/images/developing/adt-props-isLib.png b/docs/html/images/developing/adt-props-isLib.png
new file mode 100644
index 0000000000000..18bdb33923808
Binary files /dev/null and b/docs/html/images/developing/adt-props-isLib.png differ
diff --git a/docs/html/images/developing/adt-props-libRef.png b/docs/html/images/developing/adt-props-libRef.png
new file mode 100644
index 0000000000000..e61df51424e44
Binary files /dev/null and b/docs/html/images/developing/adt-props-libRef.png differ