Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Uso de jarras que utilizan clases java.beans (Introspector, BeanInfo o PropertyDescriptor)

Tengo el tarro 3ro del partido ( que no puedo cambiar ) que utiliza java.beans.Introspector , java.beans.BeanInfo y java.beans.PropertyDescriptor .

¿Cómo puedo usar ese tarro en mi aplicación Android?

No se puede cargar la clase (que usa Introspector ) del tarro del 3º partido:

 WARN/dalvikvm(780): VFY: unable to resolve static method 6325: Ljava/beans/Introspector;.getBeanInfo (Ljava/lang/Class;)Ljava/beans/BeanInfo; WARN/dalvikvm(780): VFY: unable to resolve exception class 962 (Ljava/beans/IntrospectionException;) WARN/dalvikvm(780): Verifier rejected class Lorg/thirdpartyjar/SomeClass; 

  • Android: cambiar el campo final estático privado usando la reflexión de java
  • Modo de avión en Jelly Bean
  • Obtener "java.lang.reflect.InvocationTargetException" al intentar registrar receptor de difusión de apk incrustado
  • Métodos de reflexión no funcionan cuando se utiliza proguard para la aplicación de Android
  • Recuperación de una lista de clases de un paquete en un proyecto de Android
  • ¿Cómo obtengo el nombre del método dentro de ese método?
  • ¿Cómo utilizar la reflexión para cambiar el servicio de copia de seguridad?
  • Clase personalizada que carga / reemplaza las clases nativas de Android
  • 2 Solutions collect form web for “Uso de jarras que utilizan clases java.beans (Introspector, BeanInfo o PropertyDescriptor)”

    Está claro que el paquete java.beans no está completo en android. Y la solución común es reempaquetar tanto java.beans como jar dependiendo de ellos para usar un nombre de paquete diferente en lugar de java.beans. Esto es exactamente lo que mencionó anteriormente openbeans hacer. Y una interesante qoute de android mensaje de error afirma: If you find that you cannot do this, then that is an indication that the path you are on will ultimately lead to pain, suffering, grief, and lamentation.

    Para evitar este camino empezaría por mirar en las opciones de realmente el uso de openbeans y tratando de obligar a terceros en el uso de esos. De lo que estás escribiendo no está claro si el tarro no puede ser cambiado o no se le permite ser cambiado (mencionas ambos). No conozco las implicaciones legales de cambiar frascos, pero técnicamente siempre es posible, por ejemplo, intentar hacer clases de ingeniería inversa, hacer algo de instrumentación de tiempo de construcción con algo como aspectj. Si esto no se permite, creo que la instrumentación en tiempo de ejecución se puede hacer, por ejemplo, dexmaker puede crear un proxy para su clase de terceros, que está utilizando java.beans y puede reimplementar parte de esta clase.

    También google un poco sobre el tema vi esto . Sólo utilizan el paquete java.beans y compilarlo para android. Esto parece frágil para mí, pero parece que está funcionando.

    Desafortunadamente esto no es una solución, solo ideas que quería compartir. Espero que encuentre los útiles.

    La única solución es una pesadilla de mantenimiento: Fork todos los tarros de terceros de la fuente y reescribirlos para que no usen java.beans. * Classes (posiblemente reemplazándolos por openbeans).

    A continuación, cada vez que uno de esos tarros de tercer partido libera una revisión (por ejemplo, para un error de seguridad crítico), vuelva a hacerlo todo de nuevo .

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.