¿No se puede anular el recurso xml de la biblioteca con el recurso png en la aplicación?

Question

Tengo una biblioteca de Android MyLib que contiene todo lo que necesito para mi aplicación (con Android 2.2). Esta biblioteca tiene un recurso XML:

drawable/main_background.xml 

En mi proyecto de aplicación MyApp I Referencia MyLib. Aquí quiero anular recursos específicos (es decir, marca). Por lo que añade una imagen de fondo en MyApp:

drawable/main_background.png 

Eclipse me mantiene dando este error:

[com.mycom.mylib.myapp] res\drawable\main_background.xml:0: error: Resource entry main_background is already defined. 
[com.mycom.mylib.myapp] res\drawable\main_background.png:0: Originally defined here. 

¿Cómo puedo anular el recurso en el proyecto de la biblioteca?

Answer 1

No puede anular simplemente el ID de recurso (es el ID de recurso que está anulando, no el archivo real) con un archivo con extensión diferente en Android SDK. Sin embargo, puede hacer el truco al poner en su archivo xml de proyecto con el mismo nombre (main_background.xml) y llenarlo de manera adecuada para mostrar su nuevo archivo (main_background.png), que debe cambiar el nombre anterior. Toda la sintaxis que necesita se lo expuesto aquí:

http://developer.android.com/guide/topics/resources/drawable-resource.html

, en su caso podría ser simplemente (suponiendo que poner esto en su proyecto no biblioteca como main_background.xml, y usted tiene su nueva png como main_background_new.png):

<?xml version="1.0" encoding="utf-8"?> 
<bitmap 
    xmlns:android="http://schemas.android.com/apk/res/android" 
    android:src="@drawable/main_background_new" /> 

Con la solución anterior, puede referirse a @drawable/main_background desde su proyecto y debe usar su archivo incluido con ese proyecto, en lugar de uno de biblioteca.

Answer 2

Así que una 'solución' a este problema, que no considero que haber una respuesta es la siguiente:

definir un documento XML en la biblioteca en cuestión (lo llamaremos bunny.xml) y hacer que se refiera a otro xml de un nombre similar (bunny_drawn.xml) con el contenido real que se mostrará.

Luego, en el proyecto de destino, sobrescribimos bunny.xml con otro y lo utilizan para hacer referencia a una imagen con un nombre diferente en su lugar - bunny_image.png

Sin embargo esto no resuelve el problema, en primer lugar, debido a que aren 't técnicamente anulando un png con un xml (aunque el efecto es algo cercano a eso). En segundo lugar, porque una de las características clave de anulando los recursos es que son anulados, es decir, que no se compilan en el APK:

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

Pero el bunny_drawn.xml todavía serán compilados en! Podemos sortear el segundo punto, no solo definiendo la imagen a reemplazar en la aplicación de destino, sino también reemplazando el antiguo objetivo bunny_drawn.xml con un xml en blanco. (o, como señaló Fenix, puede tener los contenidos de bunny_drawn.xml dentro de bunny.xml en el primer caso; aún queda el hecho de que el ID del recurso no puede ser reemplazado ...)

Así que mi final La conclusión es que esto debe enviarse como un error en las herramientas de desarrollo.

Answer 3

[com.mycom.mylib.myapp] res\drawable\main_background.xml:0: error: Resource entry main_background is already defined. 
[com.mycom.mylib.myapp] res\drawable\main_background.png:0: Originally defined here. 

No creo que pueda tener el mismo nombre de archivo, incluso con diferentes extensiones. Trata de nombrar el png como algo más.

Ahora, no he utilizado la anulación, así que esto parece extraño ya que es de esperar que sea así como anula el activo. Sin embargo, creo que tienes los dos activos en tu lib nombrados de la misma manera. Y que en su proyecto podría estar bien tener un activo con el mismo nombre. Sin embargo, verificaría si está bien tener diferentes tipos. XML es diferente de png, y si accede al activo desde el código puede obtener errores de tipo.

Permítanme aclarar el punto anterior. Entiendo que un proyecto de biblioteca puede tener un elemento con el mismo ID de recurso como un elemento en su aplicación.

Sin embargo, el error anterior sugiere que tanto main_background.png como main_background.xml están en el mismo proyecto ([com.mycom.mylib.myapp]) que no creo que sea correcto.

Otras lecturas

esta página se describen los diferentes tipos de proyectos, incluyendo el proyecto de biblioteca http://developer.android.com/tools/projects/index.html

Ahora no sé donde me dio la impresión de haber mirado, pero de nuevo, simplemente no lo hace indicar en cualquier lugar donde pueda anular un recurso utilizando el mismo nombre de recurso. Dios sabe por qué pensé que era una característica.

Así que no, la misma regla se aplica por lo que puedo decir, que los recursos deben nombrarse de manera única incluso en proyectos de biblioteca, de lo contrario, los identificadores de recursos generados entrarán en conflicto. (El error que obtiene)

Lo que se explica es cómo se gestionan los conflictos de recursos.

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.

El sistema utilizará el recurso con la más alta prioridad, descartando todo lo demás. Qué extraño, es que pensaría que un error de compilación no ocurriría ya que el compilador debería descartar el recurso. Esto me hace creer que el póster original tenía los activos de nombre similar en el mismo proyecto , y no en el lib y el proyecto.

No he leído en ninguna parte que esta sea en realidad una función prevista. ¿Tienes algún enlace para decir lo contrario? (comentarlos)