I read on how to reduce SKMaps.zip file size by deleting some of the files. Regarding to the same I need more information.
I deleted grayscalestyle, outdoorstyle and nightstyle folders and all the contents of sound_files (Maps/Advisor/en) directory.
There are two folders .Common and .Routing, .Common is of 28.5MB!! Are all the contents of this directory required? I tried deleting these two folders completely which resulted in map crash. If can be deleted which all files in these two folders can be deleted?
PreInstalledMaps directory is >10MB, which files can be deleted from this? I don't have preinstalled maps feature at all.
I read this, I need much more clarifications WRT other directories. Please let me know which all directories/files can be deleted as I need to reduce final APK size as much as possible.
No Routing/directions in this app.
The common directory contains files shared by all styles - the biggest file in there is the fonts file.
The fonts file provides all the required glyphs for all the character sets that the SDK supports (latin, arabic, cyrillic, chinese, etc.) - for the time being you cannot delete anything in there. In a future update there will be the option to use system fonts (instead of a fonts file).
The only workaround (at this time) would be to separate this file from the bundle, host it on your servers and download it before starting the SDK - this will be a one time operation - it will reduces the initial app size but it will increase the startup time (the first time).
The PreInstalledMaps folder - you can delete the meta folder.
Related
I'm working on developing an Android application in Android Studio. I have large files in the assets folder, so the 'install' step of the code -> build -> install -> run cycle takes a long time, and I mean several minutes (5 to 10).
What's the best way to reduce that time?
The only idea I have is to use smaller assets data while developing.
The thing is the assets don't really change that often.
Are there any other ways to have the assets "pre-installed" so they don't have to be installed over and over again as part of the app (at least just while developing)
The asset folder consists of one large sqlite file, plus a myriad of image and sound files, that all add up to over 500MB.
I found it a nice way to do it using "Expansion packs" and "Opaque Binary Files" as described here:
https://developer.android.com/google/play/expansion-files.html
https://developer.android.com/studio/command-line/jobb.html
Here's how I did it:
1) Move everything from the assets folder to somewhere else.
Of course you are free to keep things in assets, but in my case I can do without them.
2) Use the jobb tool to create an obb file from your assets.
Assuming your package name is me.name.app
jobb -d appAssets -o main.1.me.name.app.obb -pn me.name.app -pv 1
You might have to change -pv depending on your package version.
The naming chosen here main.1.me.name.app.obb is not arbitrary; it's what the Play Store will rename your file to when you upload it. See the File Name section of the docs.
3) Figure out where you should place your obb file. This is the path that Android will place your file in when the app is downloaded from the play store. I haven't deployed it to the play store yet so for all I know there could be some mistake in this step.
The path to the obb is described in the documentation as <shared-storage>/Android/obb/<package-name>/ where <shared-storage> can be obtained from Environment.getExternalStorageDirectory() and package-name is me.name.app as per our example, so the path to the obb would be:
Environment.getExternalStorageDirectory() + "/Android/obb/me.name.app/main.1.me.name.app.obb"
On my Android, the external store seems to be at "/storage/emulated/0/" but I would assume it could be different across devices.
Once you find out where the path should be, place your obb file there.
4) In your app, use StoreManager.mountObb to mount the obb to a new root path. Store this root path in a global object and use it across your application's code.
You have to go through your code and change any part that relies on the AssetsManager and change it to use regular file paths.
Your app (apk) file size is now much smaller but you still get to access your assets.
I know that files in the res directory are accessible from R.class while assets behaves like a file system, but I would like to know, in general, when it's best to use one and the other.
Can anyone help me in knowing the real differences between res and assets?
With resources, there's built-in support for providing alternatives for different languages, OS versions, screen orientations, etc., as described here. None of that is available with assets. Also, many parts of the API support the use of resource identifiers. Finally, the names of the resources are turned into constant field names that are checked at compile time, so there's less of an opportunity for mismatches between the code and the resources themselves. None of that applies to assets.
So why have an assets folder at all? If you want to compute the asset you want to use at run time, it's pretty easy. With resources, you would have to declare a list of all the resource IDs that might be used and compute an index into the the list. (This is kind of awkward and introduces opportunities for error if the set of resources changes in the development cycle.) (EDIT: you can retrieve a resource ID by name using getIdentifier, but this loses the benefits of compile-time checking.) Assets can also be organized into a folder hierarchy, which is not supported by resources. It's a different way of managing data. Although resources cover most of the cases, assets have their occasional use.
One other difference: resources defined in a library project are automatically imported to application projects that depend on the library. For assets, that doesn't happen; asset files must be present in the assets directory of the application project(s). [EDIT: With Android's new Gradle-based build system (used with Android Studio), this is no longer true. Asset directories for library projects are packaged into the .aar files, so assets defined in library projects are merged into application projects (so they do not have to be present in the application's /assets directory if they are in a referenced library).]
EDIT: Yet another difference arises if you want to package a custom font with your app. There are API calls to create a Typeface from a font file stored in the file system or in your app's assets/ directory. But there is no API to create a Typeface from a font file stored in the res/ directory (or from an InputStream, which would allow use of the res/ directory). [NOTE: With Android O (now available in alpha preview) you will be able to include custom fonts as resources. See the description here of this long-overdue feature. However, as long as your minimum API level is 25 or less, you'll have to stick with packaging custom fonts as assets rather than as resources.]
Both are pretty similar. The real main difference between the two is that in the res directory each file is given a pre-compiled ID which can be accessed easily through R.id.[res id]. This is useful to quickly and easily access images, sounds, icons...
The assets directory is more like a filesystem and provides more freedom to put any file you would like in there. You then can access each of the files in that system as you would when accessing any file in any file system through Java. This directory is good for things such as game details, dictionaries,...etc.
I know this is old, but just to make it clear, there is an explanation of each in the official android documentation:
from http://developer.android.com/tools/projects/index.html
assets/
This is empty. You can use it to store raw asset files. Files that you save here are compiled into an .apk file as-is, and the original filename is preserved. You can navigate this directory in the same way as a typical file system using URIs and read files as a stream of bytes using the AssetManager. For example, this is a good location for textures and game data.
res/raw/
For arbitrary raw asset files. Saving asset files here instead of in the assets/ directory only differs in the way that you access them. These files are processed by aapt and must be referenced from the application using a resource identifier in the R class. For example, this is a good place for media, such as MP3 or Ogg files.
Following are some key points :
Raw files Must have names that are valid Java identifiers , whereas
files in Assets Have no location and name restrictions. In other
words they can be grouped in whatever directories we wish
Raw files Are easy to refer to from Java as well as from xml (i.e
you can refer a file in raw from manifest or other xml file).
Saving asset files here instead of in the assets/ directory only
differs in the way that you access them as documented here
http://developer.android.com/tools/projects/index.html.
Resources defined in a library project are automatically imported to
application projects that depend on the library. For assets, that
doesn't happen; asset files must be present in the assets directory
of the application project(s)
The assets directory is more like a filesystem provides more freedom
to put any file you would like in there. You then can access each of
the files in that system as you would when accessing any file in any
file system through Java . like Game data files , Fonts , textures
etc.
Unlike Resources, Assets can can be organized into subfolders in the
assets directory However, the only thing you can do with an asset is
get an input stream. Thus, it does not make much sense to store your
strings or bitmaps in assets, but you can store custom-format data
such as input correction dictionaries or game maps.
Raw can give you a compile time check by generating your R.java file
however If you want to copy your database to private directory you
can use Assets which are made for streaming.
Conclusion
Android API includes a very comfortable Resources framework that is
also optimized for most typical use cases for various mobile apps.
You should master Resources and try to use them wherever possible.
However, if you need more flexibility for your special case, Assets
are there to give you a lower level API that allows organizing and
processing your resources with a higher degree of freedom.
If you need to refer them somewhere in the Java Code, you'd rahter put your files into the "res" directory.
And all files in the res folder will be indexed in the R file, which makes it much faster (and much easier!) to load them.
Use assets like a filesystem to dump any kind of files. And use res to store what it is made for, layouts, images, values.
Ted Hopp answered this quite nicely. I have been using res/raw for my opengl texture and shader files. I was thinking about moving them to an assets directory to provide a hierarchical organization.
This thread convinced me not to. First, because I like the use of a unique resource id. Second because it's very simple to use InputStream/openRawResource or BitmapFactory to read in the file. Third because it's very useful to be able to use in a portable library.
Assets provide a way to include arbitrary files like text, xml, fonts, music, and video in your application. If you try to include these files as "resources", Android will process them into its resource system and you will not be able to get the raw data. If you want to access data untouched, Assets are one way to do it.
When I complete the Android app I am developing I will want to distribute it so that about 300 image files are stored on the sdcard. Is there any way to do this within the usual automatic installation system? I don't want to hog the internal memory by including the files in res/raw.
I believe the app can now be built with an instruction to install on the sdcard so I suppose I could do that and include the files in res/raw but is there any limit on the number of files in res/raw?
If you didn't want to include the images you could utilize the APK Expansion Files mechanism:
http://developer.android.com/google/play/expansion-files.html
It will even save it to the sdcard.
Otherwise, you will either have to include the images or download them programmatically to the sdcard. As for the limits of the res/raw/assets folder I couldn't find any hard figures. The upper limit though would be the max size of the apk. You could always write a little script that would place 5k/10k/20k 1byte files and see for yourself on that upper bound. If the actual amount of files became an issue you could always zip them in the assets/raw and unzip them to external storage.
I have personally shipped an application for a client that had upwards of 500 images in the assets folder and it worked very well.
I have some configuration files that should be editable. I need to add all of them to the project before creating the .apk file. Also they should remain private to the application, then I guess that they should go in the Internal Storage.
Is it possible to do? In which folder should I put them.
One of the solutions I found is to add them to assets and move to Internal Storage in the first run, but files size is too big to duplicate the memory.
Thank you.
I have some configuration files that should be editable. I need to add all of them to the project before creating the .apk file.
By default, those two concepts are mutually exclusive. Files that are in your APK (e.g., in assets/) cannot be edited.
One of the solutions I found is to add them to assets and move to Internal Storage in the first run, but files size is too big to duplicate the memory.
Then make smaller files. This is your only option that even comes close to meeting your requirements.
I know that files in the res directory are accessible from R.class while assets behaves like a file system, but I would like to know, in general, when it's best to use one and the other.
Can anyone help me in knowing the real differences between res and assets?
With resources, there's built-in support for providing alternatives for different languages, OS versions, screen orientations, etc., as described here. None of that is available with assets. Also, many parts of the API support the use of resource identifiers. Finally, the names of the resources are turned into constant field names that are checked at compile time, so there's less of an opportunity for mismatches between the code and the resources themselves. None of that applies to assets.
So why have an assets folder at all? If you want to compute the asset you want to use at run time, it's pretty easy. With resources, you would have to declare a list of all the resource IDs that might be used and compute an index into the the list. (This is kind of awkward and introduces opportunities for error if the set of resources changes in the development cycle.) (EDIT: you can retrieve a resource ID by name using getIdentifier, but this loses the benefits of compile-time checking.) Assets can also be organized into a folder hierarchy, which is not supported by resources. It's a different way of managing data. Although resources cover most of the cases, assets have their occasional use.
One other difference: resources defined in a library project are automatically imported to application projects that depend on the library. For assets, that doesn't happen; asset files must be present in the assets directory of the application project(s). [EDIT: With Android's new Gradle-based build system (used with Android Studio), this is no longer true. Asset directories for library projects are packaged into the .aar files, so assets defined in library projects are merged into application projects (so they do not have to be present in the application's /assets directory if they are in a referenced library).]
EDIT: Yet another difference arises if you want to package a custom font with your app. There are API calls to create a Typeface from a font file stored in the file system or in your app's assets/ directory. But there is no API to create a Typeface from a font file stored in the res/ directory (or from an InputStream, which would allow use of the res/ directory). [NOTE: With Android O (now available in alpha preview) you will be able to include custom fonts as resources. See the description here of this long-overdue feature. However, as long as your minimum API level is 25 or less, you'll have to stick with packaging custom fonts as assets rather than as resources.]
Both are pretty similar. The real main difference between the two is that in the res directory each file is given a pre-compiled ID which can be accessed easily through R.id.[res id]. This is useful to quickly and easily access images, sounds, icons...
The assets directory is more like a filesystem and provides more freedom to put any file you would like in there. You then can access each of the files in that system as you would when accessing any file in any file system through Java. This directory is good for things such as game details, dictionaries,...etc.
I know this is old, but just to make it clear, there is an explanation of each in the official android documentation:
from http://developer.android.com/tools/projects/index.html
assets/
This is empty. You can use it to store raw asset files. Files that you save here are compiled into an .apk file as-is, and the original filename is preserved. You can navigate this directory in the same way as a typical file system using URIs and read files as a stream of bytes using the AssetManager. For example, this is a good location for textures and game data.
res/raw/
For arbitrary raw asset files. Saving asset files here instead of in the assets/ directory only differs in the way that you access them. These files are processed by aapt and must be referenced from the application using a resource identifier in the R class. For example, this is a good place for media, such as MP3 or Ogg files.
Following are some key points :
Raw files Must have names that are valid Java identifiers , whereas
files in Assets Have no location and name restrictions. In other
words they can be grouped in whatever directories we wish
Raw files Are easy to refer to from Java as well as from xml (i.e
you can refer a file in raw from manifest or other xml file).
Saving asset files here instead of in the assets/ directory only
differs in the way that you access them as documented here
http://developer.android.com/tools/projects/index.html.
Resources defined in a library project are automatically imported to
application projects that depend on the library. For assets, that
doesn't happen; asset files must be present in the assets directory
of the application project(s)
The assets directory is more like a filesystem provides more freedom
to put any file you would like in there. You then can access each of
the files in that system as you would when accessing any file in any
file system through Java . like Game data files , Fonts , textures
etc.
Unlike Resources, Assets can can be organized into subfolders in the
assets directory However, the only thing you can do with an asset is
get an input stream. Thus, it does not make much sense to store your
strings or bitmaps in assets, but you can store custom-format data
such as input correction dictionaries or game maps.
Raw can give you a compile time check by generating your R.java file
however If you want to copy your database to private directory you
can use Assets which are made for streaming.
Conclusion
Android API includes a very comfortable Resources framework that is
also optimized for most typical use cases for various mobile apps.
You should master Resources and try to use them wherever possible.
However, if you need more flexibility for your special case, Assets
are there to give you a lower level API that allows organizing and
processing your resources with a higher degree of freedom.
If you need to refer them somewhere in the Java Code, you'd rahter put your files into the "res" directory.
And all files in the res folder will be indexed in the R file, which makes it much faster (and much easier!) to load them.
Use assets like a filesystem to dump any kind of files. And use res to store what it is made for, layouts, images, values.
Ted Hopp answered this quite nicely. I have been using res/raw for my opengl texture and shader files. I was thinking about moving them to an assets directory to provide a hierarchical organization.
This thread convinced me not to. First, because I like the use of a unique resource id. Second because it's very simple to use InputStream/openRawResource or BitmapFactory to read in the file. Third because it's very useful to be able to use in a portable library.
Assets provide a way to include arbitrary files like text, xml, fonts, music, and video in your application. If you try to include these files as "resources", Android will process them into its resource system and you will not be able to get the raw data. If you want to access data untouched, Assets are one way to do it.