I tried to make a .map file to use it in my android application. My point is to show map on screen with help of mapsforge library. Library requires a .map file. The problem is generating it with osmosis mapfilewriter plugin. When I use command
./osmosis --rx file=/home/user/poland.osm --mw file=result.map bbox=51.09,16.9,51.14,17
I get
SEVERE: Thread for task 1-rx failed
java.lang.OutOfMemoryError: Java heap space
I tried using another order of arguments but it also doesn't work. I also tried using -Xmx1200m option to increase javas heap memory but usage of memory was this same and didn't help.
I would be grateful for help.
Use the parameter type=hd.
The type parameter has two options ram and hd. Although I don't see that the documentation doesn't explicitly state what hd means, I would guess it means "hard disk", meaning it would offload data to disk, rather than keeping it all in memory.
The resulting command would be then:
./osmosis --rx file=/home/user/poland.osm --mw file=result.map bbox=51.09,16.9,51.14,17 type=hd
If you have enough memory, you need to tell Java about it (it will only use a limited amount otherwise); but this is not an argument passed directly to osmosis.
On Windows, you can follow this advice given by Emilie Laffray on the OSM-dev list:
In osmosis.bat is the following line... REM # JAVACMD_OPTIONS - The
options to append to the java command, typically used to modify jvm
settings such as max memory.
so, either modify osmosis.bat or, create a new file called osmosis.bat
in the all users profile directory or your profile directory, to
include a 'set JAVACMD_OPTIONS = -Xmx1024M' line (to set maximum
memory usage to 1GB, if you have enough RAM)...
On Linux (and I'd assume Mac OS X also), you can create the file ~/.osmosis
containing the line
JAVACMD_OPTIONS=-Xmx1024M
which will be loaded by osmosis on startup. Note that both examples above use the value 1024M, i.e. you're giving Java access to 1024 MB of RAM - you could use a different value depending on your system.
Related
I want to simulate a drive using the SKNavigationSettings.SKNavigationType.FILE. Is there an easy way to generate one of these files? I see the Seattle.log in the demo project, and I could just edit some coordinates and make my own however it would be great to simulate a real drive. Also I am not sure what all of the entries are:
"47.655942 -122.137419, 11.000000, 19.000000, 0.000000, 1380803959889470, 03.10.2013 15:39:19" (what are 11.000000, 19.000000, 0.000000?)
Update: I still do not have a way of doing this and I do not understand some of the values (listed above). The file is Seattle.log and it just consists of a bunch of lines like the one above separated by newlines.
You can find the full SDK documentation here.
https://www.developer.skobbler.com/docs/android/3.0.2/index.html
Yes, you can obtain a logging file with data collected from a real drive. You can use the startLoggingPositions(String filePath, SPositionLoggingType positionLoggingType) and public boolean stopLoggingPositions() from the SKPositionLoggingManager class (com.skobbler.ngx.positioner.logging package) to accomplish that. You will obtain a log file (if the positionLoggingType is set to SK_POSITION_LOGGING_TYPE_LOG) similar to Seattle.log at the specified path.
The values stored in the file are (in this order): Latitude, Longitude, Course, Speed, Accuracy, Timestamp.
I'm trying to do the impossible and it doesn't seem to be working. The overall goal is this: I have a Component interface and I would like to show the user a list of classes on the classpath that implement that interface. The trick is, it has to run in Android.
Near as I can tell this is impossible to do at run time. The java mechanism (ServiceLoader) has been intentionally crippled by the Android toolchain, so it doesn't work. Guava doesn't work on Android, nor does ClassUtils, nor does Reflections.
At this point I've been yak shaving for 8 hours strait and there's no end in sight, so I'm looking for alternative approaches. My current thinking is to build a plugin (very much like sbt-spi, but not, because Android hates SPI) that can generate a text file at compile time that lists every class which implements the interface, so that at runtime I can open that file as a resource and then use reflection to start building them. Is that a reasonable idea? How should I go about it? (my current approach is "read the sbt-spi plugin source and try to copy it", but this seems like a scenario where "ask for wisdom" is a better approach)
Got it! I ended up using sbt-spi after all (huzzah not reinventing any wheels!) and just moving the output into the intermediate assets directory as part of the resourceGenerators task:
lazy val androidEntryPoint = (project in file("android-entry-point"))
.dependsOn(core, components, androidComponents)
.enablePlugins(SpiPlugin)
.settings(commonSettings: _*)
.settings(resourceGenerators in Compile += Def.task{
// This task copies the list of Components to the appropriate place to ensure
// it gets included in an accessible place in the APK
val res = collectResources.value._1 // item _1 here is for assets, item _2 is for resources. See the output of sbt "show androidEntryPoint/android:collectResources"
mapExport.value.toSeq.map { name =>
IO.move(target.value / name, res / name)
res / name
}
}.taskValue
)
That said, I'd love to hear a better approach if you can think of one. If none turn up in the next week or so I'll mark this one the answer.
In dex code (e.g., as produced by the dexdump tool), for each method definition I see "ins" and "outs" in addition to other metadata such as "registers", "insns size".
I am instrumenting dex code to introduce new registers. The instrumentation is failing, and I suspect that I may have to change the "ins" and "outs" values based on the number of new registers I add.
So my question is: What do those "ins" and "outs" represent?
(fyi: I am using dexlib2 for this.)
These fields are documented at http://source.android.com/devices/tech/dalvik/dex-format.html.
ins_size | the number of words of incoming arguments to the method that this code is for
outs_size | the number of words of outgoing argument space required by this code for method invocation
ins_size is mostly self-explanatory - it's the number of 32-bit words required to store the method arguments (including the implicit "this" argument, for non-static methods). All arguments require 1 "word" except longs (J) and doubles (D), which require 2 words.
outs_size basically the opposite. outs_size must be set large enough to hold the arguments for any method call that occurs within the method.
If you want to instrument a dex file without having to worry about details like this, you might consider using dexlib2 (the library developed for and used by smali/baksmali to read/write dex files). The library is available in the maven repository, so it's easy to link against if you're using gradle/mvn.
I want to get the application size (in bytes). The way I tried was as follows:
PackageStats ps = new PackageStats(packageInfo.packageName);
int size = ps.codeSize;
This returns 0 every time. (Bascially every value returned is 0 - cacheSize, dataSize etc)
I do not want to use reflection as mentioned here (as its a non documented way)
So is there any way to fetch this information ?
One definition of application size is the size of the apk file in bytes.
You can get that by doing new File() on the ApplicationInfo.sourceDir value for the application, and then doing a File.length() on that file.
Contrary to the sound of the class name, PackageStats.class doesn't access system on your phone and find the size of your app, data, and cache files (wish it did). It is used to pull this information (if available) from a parcel, or to take a package and write this information if provided by the package into a parcel.
Using zmarties approach, new File(), is a workable solution.
I need to modify a so inside an Android APK.
The task is to rename the dynamic symbols in side the so (which is the function name).
For example, change from Java_com_example_abc_.... to Java_com_yahoo_zzz_....
I try to use WinHex directly search and replace text words, the apk startup error.
Seems like the .hash section also needs to be updated, but i do not know how to update the .hash section.
My question is what is the correct or preferable way to rename the dynamic Symbol?
I heave been stuck for 3 days, please help me, thank you very much!
Found a post might related, but he didn't gave the alternative solution.
https://sourceware.org/ml/binutils/2006-03/msg00266.html
I heave been stuck for 3 days, please help me,
What you are trying to achieve is effectively impossible.
ELF files have complicated internal structure, and what you want to do requires that you break it up and re-assemble the parts. An analogy would be to break an Intel CPU into transistors and re-assemble an AMD CPU from them.
Found a post might related
It is related. Quote:
Basically it does the following:
loop over .dynsym and re-create .dynstr
re-create the .hash table from scratch
calculate new lma/vma, new memory layout (.dynstr size changed!)
fix the contents of .dynamic, according to the new layout
fix .rel.dyn
fix .rel.plt
fix .dynsym again
write out the new section contents
In copy_section: exclude the rewritten sections from being copyied.
Currently it seems to create a syntactically valid ELF file, but as
the distance between .plt and .got changes, the relative addressing in
.plt is broken. Additionally the .got has to be fixed again.
So the author managed to glue together something that looks like an AMD CPU, but which doesn't work.
Sure, you can spend another 2 weeks to understand what the author did, and then another 3 weeks to fix the remaining broken pieces. And after that, you may get something that kind of sometimes works.
Your time is likely better spent elsewhere.
Have a look at LIEF, but try to keep them the same length
native_lib = 'my_native_lib.so'
lib = lief.parse(native_lib)
for x in lib.exported_symbols:
if x.name == 'Java_com_example_abc':
x.name = 'Java_com_foobarr_zzz'
lib.write(native_lib) # overwrite
The ability to change names in shared libraries was added in Patchelf: https://github.com/NixOS/patchelf/commit/da035d6acee1e5a608aafe5f6572a67609b0198a
It should be available in the next release (after 0.17.2). Meanwhile you can build the tool following the instructions in https://github.com/NixOS/patchelf#compiling-and-testing
To use it, create a map file with two names (old and new) per line, and invoke Patchelf with:
$ patchelf --output libPatched.so --rename-dynamic-symbols map_file libOriginal.so
Please provide feedback if you find issues. Thanks!