¿Cómo hacer referencia a los "activos" de Android a través de paquetes?

Tengo una aplicación Android que se publica en una versión 'gratuita' y 'profesional'. He configurado mi proyecto con un proyecto de base 'biblioteca' que se hace referencia desde ambas versiones, de modo que mi conjunto de paquetes se parece a esto:

Com.example.myapp
Com.example.myapp.free
Com.example.myapp.pro

Una de las clases de Activity en mi proyecto 'library' de base carga un archivo de ayuda en un WebView: WebView.loadUrl ("file: ///android_asset/help.html"). Esta clase se extiende en las versiones 'gratis' y 'pro' (por razones fuera del alcance de esta pregunta), pero me gustaría que ambas versiones hicieran referencia al mismo archivo HTML (es decir, el del paquete padre). Sin embargo, bajo mi configuración actual, el archivo HTML debe duplicarse en la carpeta 'assets' en los paquetes 'com.example.myapp.free' y 'com.example.myapp.pro' para el archivo "file: // / Android_asset / "URI para trabajar.

¿Hay una manera de especificar el "file: /// android_asset /" URI de tal manera que accede al directorio 'assets' en el paquete padre?

Una solución parcial que encontré implica leer el archivo HTML desde el directorio 'raw' y luego empujar la cadena resultante a mi objeto WebView, pero esto sería desordenado para hacer algo más que una página HTML solo texto (por ejemplo, una con imágenes, Como mi uno).

Aclamaciones.

Ya que Andrew White no explicó cómo hacer lo que recomienda contra, te mostraré:

Context otherContext = context.createPackageContext("other.package.name", 0); AssetManager am = otherContext.getAssets();

Eso no parece tan malo. Y he comprobado que no hay necesidad de que los dos paquetes compartan un ID de usuario.

Como desarrollador que tiene versiones profesionales y gratuitas por ahí, puedo decir por experiencia, no intente compartir recursos entre aplicaciones . Incluso si usted consigue que funcione, usted terminará para arriba con más molestia que vale.

Si es absolutamente necesario que haga esto, cada aplicación debe compartir el mismo usuario del sistema y debe crear un contexto en una aplicación que imita al otro. Estos no son difíciles de hacer, pero puede ser una pesadilla de mantenimiento.