I have a library project which includes some TFLite models. I want to be able to distribute the library and include the models in the AAR's assets folder. I've put everything in the assets folder and when inspecting the resulting AAR, I see that the models exists.
My question is, how can I access these models? either from the library itself (preferably) or from the application that uses it?
If I look try and access the assets the normal way for an application
AssetManager am = context.getAssets();
am.list(assetFolder)
I get an empty list.
I saw many posts about including assets in an android AAR library but none that referred to how to actually use these assets, so am I missing something very basic here?
EDIT
This is how the AAR is structured
Inside the assets folder I have a resources folder which contains the models
so
- AAR
-- assets
--- resources
---- model
I tried different values for assetFolder in the code, /, resources, all gave empty lists
Try with:
am.list("resources/model")
Just tested with aar and it works. Be careful, list returns directories and files in the specified path, it doesn't show files in subfolders
Related
I have some files that I want to read from my app.Currently, I have to do the following:
Check if the file exists in the files directory.
If it doesnt, then copy the files from assets to the files directory
If it does, then, skip step 2
So, is it possible to not copy the files ? This increases the size of my app (uselessly) as there is an extra copy of all the files.
Note, that I have to access the file using getfiles(). I am using a library that doesnt work if I give the uri of my assets folder.
So, it it somehow possible to compile the app with some files already in the files directory ?
Internal storage for you app is created when application is installed so there is no way to provide files there during compile time, that would be magic.
You could try creating ContentProvider for sharing your files stored inside assets folder.
Besides, you should tell which library you are using. Then I may be able to suggest something more precise.
I have an NDK library that I am creating that needs to contain and access a binary data file (.dat extension). I am having trouble getting the compiled library to see this file. To make things a little more difficult, I am doing this within a library package.
I think it would work if, during my Android.mk file, I copy this .dat file to my app's resources folder, and then access that from within the app, but I feel like there must be a better way.
Any suggestions?
Instead of resources, put it in the assets folder; NDK provides API to access assets from native code.
Often, we unpack some "files" from the resources or assets to the file system (e.g. /sdcard) on the first run of the app after install. This approach works best when the files must be used by external apps and libs (e.g. to play sounds), or when these files will be changing.
Finally, you can link the data into your .so during ndk-build. This will resolve the question how the .dat file will be copied into the app folder, but reading it may be tricky, and modifying - impossible. You don't need to create a huge library. You can create a mock-up library that contains the data. If I understand correctly, you can ignore the file structure, headers, etc. You only need a file named lib something .so in your libs/armeabi (or other) folder.
As we all know by now, Android's Eclipse+ADT IDE framework doesn't support (re)using assets from a Library Project.
Instead, any asset resources used by an application must be stored in the assets/ directory of the application project itself.
My problem is that I have 8 (eight!) applications using the same Library Project that uses assets and as a result of the aforementioned limitation I have to copy/duplicate and sync each of the asset files to all 8 (eight!) applications.
This is a maintenance nightmare and it is error prone, too.
Any idea how to work around this by sharing a single copy of each asset among multiple application projects?
Note: I'd like to avoid an OS or filesystem dependent solution like hardlinks or softlinks. I prefer a solution like context.getAssets(), if it indeed does the work.
Maybe things have changed since you posted the question, but I was able to reuse asset files from another project in my Android project. I created my project's assets folder as a linked folder. I posted a sample project to show how it works.
I'm pretty new to eclipse and Android and I'm trying to add some files to the assets folder, but certain files and directories are not being included in the .apk file.
I have set-up the following structure in the solution:
/assets
/textures
/test.png
/splash.png
/xml
/testData.xml
I don't know if there is a specific way to get eclipse to re-build/compile the project and add the new assets to the assets folder in the .apk, but the /xml subfolder (and its contents) are not in the apk. Subsequently I get FilenotFoundExceptions thrown when I deploy the app. The textures are all included.
How can I force a recompile and rebuild of the apk and is there anywhere to manually check which files are included in the project (like an assets manifest file)?
As far as I know there are no restrictions placed on hierarchy or file formats for within the assets folder. Also, when I dragged the files from the desktop to the solution explorer, I selected 'copy files to project'.
Thanks
It appears one cannot use upper-case letters in the naming of files within the assets folder. Contrary to my example above, I was actually using camel-backed file names within the folders. After changing the file names to lower-case, the apk was automatically re-built with the assets the next time I deployed
In a class belonging to a Library project I call:
webview.loadUrl("file:///android_asset/info.html", null);
Unfortunately, this only works if I duplicate the file info.html into the Application's project asset folder as well.
Is there a way to tell an Android library code: "look for this file in the library's assets folder, not in the application's assets folder" ?
This answer is out of date, the gradle build system and AAR files support assets.
From the Android Docs:
Library projects cannot include raw assets
The tools do not support the use of raw asset files (saved in the assets/ directory) in a library project. Any asset resources used by an application must be stored in the assets/ directory of the application project itself. However, resource files saved in the res/ directory are supported.
If you want to include files from a Library project, you'll need to put it in the resources instead of the assets. If you're trying to load HTML files from your library project into a WebView, this means that you'll have to go a more roundabout method than the usual asset URL. Instead you'll have to read the resource data and use something like loadData.
This is now possible using the Gradle build system.
Testing with Android Studio 0.5.0 and v0.9 of the Android Gradle plugin, I've found that files such as
MyLibProject/src/main/assets/test.html
are correctly packaged in the final application and can be accessed at runtime via the expected URL:
file:///android_asset/test.html
You can achieve this by creating a symbolic link in the project's asset folder that points to the directory in the library project.
Then you can access as below:
webview.loadUrl("file:///android_asset/folder_in_a_libary_project/info.html", null);
Okay. Ive been stressing out and losing sleep about this for a while. Im the type of person that loves API creation, and HATES complicated integration.
There arent many solutions around on the internet, so im quite proud of what Ive discovered with a bit of Eclipse Hackery.
It turns out that when you put a file in the Android Lib's /assets folder. The target apk will capture this and place it on the root of the APK archive. Thus, making general access fail.
This can be resolved by simply creating a Raw Java Library, and placing all assets in there, ie (JAVALIB)/assets/fileX.txt.
You can in turn then include this as a Java Build Path Folder Source in
Project > Properties > Java Build Path > Source > Link Source.
Link Source
Click on Variables. and Add New Variable, ie VAR_NAME_X. location : ../../(relative_path_to_assets_project)
Click Ok
Now, when you build and run your app, the assets folder in the APK will contain your (GLOBAL Library) files as you intended.
No need to reconfigure android internals or nothing. Its all capable within a few clicks of Eclipse.
I confirm that Daniel Grant's approach works for at least the following situation: target project does NOT have an asset folder (or the folder is empty, so you can safely delete it).
I did not setup any variable.
Simply setup a LinkSource as follows (just an example)
Linked folder location: /home/matthew/workspace_moonblink/assetsForAdvocacy/assets
Folder name : assets
The "assetsForAdvocacy" is a Java project, (created with New- Project - Java Project) with empty src folder, and a new folder named "assets", which now provides the entire assets folder for the target project.
This is a fairly straightforward way within Eclipse to provide assets re-use across many different projects IF they do not already have assets, good enough to get going with. I would probably want to enhance it to become a content provider in the long run, but that is a lot more development.
My project accesses the assets with the following code:
String advocacyFolderInAssets = "no_smoking/"; //a folder underneath assets/
String fn =advocacyFolderInAssets+imageFilename;
Bitmap pristineBitmapForAdvocacy = getBitmapFromAsset(context, fn);
I use Motodev Studio 3.1.0 on Ubuntu. It would not let me 'merge' a new assets folder in the new assets-only project onto an existing assets folder in the target project.
If you want to use a setup where multiple derivate products are created from one library you might consider using svn:externals or similar solution in your SCM system. This will also do the trick that static assets like online help may be versioned seperately from the android source code.
I found this older question, it might help you, too.
This is the official way Google uses to archive this (from the above post): Link