Develop Reference

OSMDroid Offline map with zip from custom server

I'm having a really hard time to get OSMDroid working with our custom tile server. I'm getting our tiles in a zip file which has the following structure:
ZoomLevel/Y/X
I've tried unzipping the zip to the osmdroid/tiles folder and the osmdroid/tiles/Mapnik folder but none of them seem work. I think I need to use the FileBasedTileSource but I don't know what to put in the aName and URL part of the method.
I'm trying to download specific areas as a zip file for use in offline situations, which on Google Maps works perfectly but I want to try out OSMDroid and see of the performance is better.
Can anyone give me some pointers on how to get this working?

Zip archives for osmdroid must have the following structure
{Source}/Z/X/Y.{extension}
Then tell osmdroid to use a tile source whose name matches exactly {Source}. Everything should be automatic.
Also, consider using sqlite database, they are generally faster

Not displaying tiles in MOBAC with custom Maperitive tiles source

I need to generate a .sqlitedb map file for an Android app containing the map of a small city, I tried using Mobile Atlas Creator 1.9.14 by itself, but it only displays red crosses, no tiles(I use a proxy with authentication, and i configured it on the settings/network tab), I don't know what to do there. I then heard about Maperitive and I downloaded a .osm.pbf file from GeoFabrik to use as source, generated a Tiles folder i needed and followed this instructions to use it on MOBAC as custom source.
It does nothing at all, I still get the same red crosses everywhere, but everyone else seems to have it working just fine. What am I doing wrong?

Had the same problem, the template file from MOBAC has a lot of comments. After removing them it worked! My xml file is now very simple, even the <sourceType> seems not to be necessary. Here it is:
<localTileFiles><name>Maperitive Tiles</name><sourceFolder>/ed/map_composer/Maperitive/Tiles</sourceFolder><backgroundColor>#00000000</backgroundColor></localTileFiles>

Android DDMS Loaded GPX file Pausing Itself

I am loading a GPX file into my emulator.
THE PROBLEM
The file has 7226 points (it says so in the Point Count column) so the file is being loaded in correctly. However, the problem happens when I press the play button it only reads in about 4 points before it then pauses itself. This is not the functionality I want.
THE QUESTION
How do I make it run through the entire file without it pausing itself?
Thanks in advance

Just for the sake of answering the question from my research and for those of you looking for a solution yourself.
I couldn't manage to get the entire GPX file loaded in via the DDMS even when using different types of converters that you can find online.
The solution in the end was to have a set of classes which decode a GPX file into a set of locations and then do whatever you want with those.
I hope this helps even it is just confirming your thoughts that it wont work (well i couldn't work it out!) :)

apk file size increased from 175k to 1711k with minor change -- what's with that?

With the fantastic help of Tim on this thread Controlling Android app with bluetooth mouse/ presenter I added bluetooth remote control of my application. After finishing this, I noticed my apk file went from 175k all the way to 1711k - 10 times larger! I have implemented the bluetooth changes on a test application without seeing any change in file size so I am not sure what caused this. I did have some kind of Eclipse problem in the middle of this and had to do a rebuild to get the source to run again so maybe that had something to do with it.
Searching for file size change here and on Google gives me questions of people who want to make larger files to hold more stuff, not my question. I can't seem to find relevant answers.
The application has no graphics, pdf's, or other files of any size at all. It just reads some GPS stuff, does some math, and displays the results as text.
Is there some way to get the file size back down? Is there an Eclipse option? This is my first real (non test) application and it is finished and working but I am concerned with the file size increase.

You can check the contents of apk file easily. An apk file is simply a zip file with different extension. Just replace .apk with .zip and unzip it. Then diff the contents with your previous .apk file and find out what file makes the difference.

I encountered a similar problem with the APK size. One way to check out which resources are the culprits is to 'Open Editor Log' in Console.
Some helpful explanations can be found here:
Unity build project game 2d to apk with huge size because textures
https://docs.unity3d.com/432/Documentation/Manual/ReducingFilesize.html

Accessing assets in Android NDK via filesystem

I'm porting a rather large game engine written in C++ from Windows/Mac to Android. There is a lot of pre-existing code to read assets for games. In addition, there is quite a bit of code doing file system calls (stat'ing the files to make sure they exist, looking up all of the files and directories inside of a directory, etc.)
Right now, I'm focusing on just getting something up and running as quickly as possible, so I'd prefer not to have to rewrite a lot of this. What would be a good way of getting our game assets onto the device and accessing them with minimal changes to our existing standard C++ file system API usage?
I've got some basic support implemented already using the Asset Manager API, but that doesn't support the file system calls and I'm concerned that the 1 MB asset size limit is going to bite me at some point.
I've also looked at OBB, but the tools for creating an OBB file don't look like they are part of the current SDK/NDK. Otherwise, that looks like it would be perfect.
Is it a horrible idea to package up all of the files and just extract them on the SD Card the first time the app is run? Or is there some better way of dealing with this?
Update: I'm also not very concerned on being able to run on a broad range of devices, I am specifically looking at newish tablets, probably the 10.1" Samsung Galaxy tab.

We ran into a similar problem in developing our (data-file-heavy) app, and we ended up deciding to keep the APK tiny and simply download our data files on first run; they're going to have to be downloaded either way, but a small APK works much better on older devices without a lot of internal storage. Plus, you can potentially rig up a way for people to copy over the files directly from their computer if they have a limited data plan or a slow internet connection on their phone.
The "Downloader" sample app in apps-for-android (confusingly buried under "Samples") is almost a fully-implemented solution for this - you can pretty much just plug in the particulars of your data files and let it do the rest.

I wrote an app that relies on putting a good amount of native code into the Android filesystem. I did this by packaging the files into the APK as 'resources'. Instead of pushing them to the SD card, you can put then into the application's private namespace, I.E. /data/data/com.yourdomain.yourapp/nativeFolder.
For details on how to accomplish this, you can see my answer to this question.
It's fairly simple to package to just unpack them on the first run and never worry about them again. Also, since they're under the application's namespace, they should be deleted if/when someone were to decide to delete your app.
EDIT:
This method can be used to put anything into the app's private area; /data/data/com.yourdomain.yourapp/
However, as far as I know, your application has to be the one to create all the folders and sub-folders in this area. Luckily this is fairly easy to do. For example to have your app make a folder:
Process mkdir = Runtime.getRuntime().exec("mkdir " +localPath);
That works as it would in most linux shells. I walked through the assets folder I packaged into my APK, made the corresponding directories and copied all the native files to those directories.
What you might be more concerned with is the limited Android shell. There are many commands that you might want that aren't present. stat for example isn't available, so all of this may be moot if your native code can't make it's system calls.