Related
This all works on stock/nonroot phones
I got Mono running on Android.
http://www.koushikdutta.com/2008/12/mono-on-android-success-at-last.html
Started working on Java/C# interop and found out that DLR works on Mono:
http://www.koushikdutta.com/2009/01/microsoft-dlr-and-mono-bring-python-and.html
As a result, you can write applications in Python and Ruby on Android too now.
Anyhow, if anyone else is interested in working on this project with me, please let me know! I've already gotten all the relevent source hosted at Google Code: http://code.google.com/p/androidmono. Basically the next bit of work involves implemeting a Java interop using the DLR.
Nifty.
As for Dalvik & JIT, I think dexopt already replaces some heavy usage calls with inline native code. Hopefully dalvik vm will get full JIT in the future?
This makes me very happy!!!
Thank you for your work!!
jashsu said:
Nifty.
As for Dalvik & JIT, I think dexopt already replaces some heavy usage calls with inline native code. Hopefully dalvik vm will get full JIT in the future?
Click to expand...
Click to collapse
It doesn't do any inline native replacements: dexopt optimizes the dex file. Which includes inline dex byte code replacements. There is no JIT at all, but Google said it would be something definitely on the horizon. Personally I think DEX is a pretty stupid move on Google's part; they could have just gone with CIL-- and write a Java compiler for that instead. The Mono JIT compiler works on many platforms; so V1 of Android could have been running JIT compiled native code with that route... which is an order of magnitude better in performance.
I'm going to be doing some performance comparisons of Mono vs Dalvik; Mono will obviously win, but it will be interesting to see the margin. I'll also experiment with binding Mono to the Android runtime to create Android applications in C#.
Optimization
Virtual machine interpreters typically perform certain optimizations the first time a piece of code is used. Constant pool references are replaced with pointers to internal data structures, operations that always succeed or always work a certain way are replaced with simpler forms. Some of these require information only available at runtime, others can be inferred statically when certain assumptions are made.
The Dalvik optimizer does the following:
For virtual method calls, replace the method index with a vtable index.
For instance field get/put, replace the field index with a byte offset. Also, merge the boolean / byte / char / short variants into a single 32-bit form (less code in the interpreter means more room in the CPU I-cache).
Replace a handful of high-volume calls, like String.length(), with "inline" replacements. This skips the usual method call overhead, directly switching from the interpreter to a native implementation.
Prune empty methods. The simplest example is Object.<init>, which does nothing, but must be called whenever any object is allocated. The instruction is replaced with a new version that acts as a no-op unless a debugger is attached.
Append pre-computed data. For example, the VM wants to have a hash table for lookups on class name. Instead of computing this when the DEX file is loaded, we can compute it now, saving heap space and computation time in every VM where the DEX is loaded.
All of the instruction modifications involve replacing the opcode with one not defined by the Dalvik specification. This allows us to freely mix optimized and unoptimized instructions. The set of optimized instructions, and their exact representation, is tied closely to the VM version.
Most of the optimizations are obvious "wins". The use of raw indices and offsets not only allows us to execute more quickly, we can also skip the initial symbolic resolution. Pre-computation eats up disk space, and so must be done in moderation.
There are a couple of potential sources of trouble with these optimizations. First, vtable indices and byte offsets are subject to change if the VM is updated. Second, if a superclass is in a different DEX, and that other DEX is updated, we need to ensure that our optimized indices and offsets are updated as well. A similar but more subtle problem emerges when user-defined class loaders are employed: the class we actually call may not be the one we expected to call.
These problems are addressed with dependency lists and some limitations on what can be optimized.
Click to expand...
Click to collapse
Koush said:
Personally I think DEX is a pretty stupid move on Google's part; they could have just gone with CIL-- and write a Java compiler for that instead. The Mono JIT compiler works on many platforms; so V1 of Android could have been running JIT compiled native code with that route... which is an order of magnitude better in performance.
I'm going to be doing some performance comparisons of Mono vs Dalvik; Mono will obviously win, but it will be interesting to see the margin. I'll also experiment with binding Mono to the Android runtime to create Android applications in C#.
Click to expand...
Click to collapse
Google had different objectives, they didn't go after maximum performance. Remember, that handsets have different constrains than desktops and laptops. So they went after minimizing RAM usage (byte code interpreter => maximum possible sharing of read-only memory pages among processes) and battery life. Performance had to be acceptable, not priority.
You would not be able to fit everything into RAM if you used Mono and you would get the patent problems with Net/Mono/etc as a bonus.
lu_tze said:
Google had different objectives, they didn't go after maximum performance. Remember, that handsets have different constrains than desktops and laptops. So they went after minimizing RAM usage (byte code interpreter => maximum possible sharing of read-only memory pages among processes) and battery life. Performance had to be acceptable, not priority.
You would not be able to fit everything into RAM if you used Mono and you would get the patent problems with Net/Mono/etc as a bonus.
Click to expand...
Click to collapse
.NET, C#, IL, et al are all ECMA standards. Mono is LGPL/GPL. There are no patent or licensing issues with it that is unfamiliar to the OHA. They reuse plenty of open source projects.
An interpreter is not power efficient OR performant, simply due to the fact is it doing the 10 times as much work to do the same thing as native code. In addition, Mono features an Ahead Of Time compiler (AOT) that would let you compile everything to native code before it even hits the phone (or just once, and cache it). Most of Android's power and memory optimizations currently comes from Google's application life cycle (activities can be killed and resumed at the system's whim) -- that has nothing to do with Dalvik. I'm not criticizing the API or the implementation, just the runtime.
They could have spent their time making the Mono runtime play nicely with the shared memory subsystem.
I'm rebuilding mono with a minimal configuration to check out the disk and memory footprint.
Koush said:
Not that most of you will care, but I got Mono running on Android.
Click to expand...
Click to collapse
I'm a noob.... how can I install this? Very good Job Kush!
pic.micro23 said:
I'm a noob.... how can I install this? Very good Job Kush!
Click to expand...
Click to collapse
I haven't released anything yet. I'm trying to figure out how to statically link all it's dependencies, minimize the size, bind to the Android runtime, convert DEX to CIL and then CIL to ARM, and all sorts of other goodness. Basically a lot of experimenting to do before anything is "released". It's just in proof of concept phase right now.
Dalvik sucks
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
Koush said:
Dalvik sucks
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
Click to expand...
Click to collapse
Lol. nice article Koush. It's surprising mono is that much faster
Koush said:
I haven't released anything yet. I'm trying to figure out how to statically link all it's dependencies, minimize the size, bind to the Android runtime, convert DEX to CIL and then CIL to ARM, and all sorts of other goodness. Basically a lot of experimenting to do before anything is "released". It's just in proof of concept phase right now.
Click to expand...
Click to collapse
Just read the dalvik vs mono article. It's certainly interesting work. I agree that by ignoring JIT they're certainly not going after the most beneficial optimizations. That said, I don't think it's something they've completely excluded from future implementation.
I think you should consider trying to get Mono added as an external project. If nothing, having unofficial support for a vm which supports C#/CIL could bring in a significant amount of developer interest from the WinMo dev community. The coretech team would be the folks to set up a new project.
I've now gotten mono working on all G1s. You don't need Debian OR root. Still a couple kinks to work out, but I have it on the market for anyone interested in playing with it. More information at the link below.
http://www.koushikdutta.com/2009/01/mono-for-android-now-available-on.html
I thought this was only a platform for development but its made my g1 much faster and reduced memory from steel and stock browsers as well. My market is still 12 mb and mono is about 11 mb. Is this normal?
Also everytime, I run mono, does it do the same thing it does the first time it was installed and opened?
Sorry, i know nothing about mono but i can tell its definitely optimizing the performance on the g1 though.
great work koushe,
hbguy
This awesome, I have been waiting to see how this all turned out after reading your first post about it a few days ago.
hbguy said:
I thought this was only a platform for development but its made my g1 much faster and reduced memory from steel and stock browsers as well. My market is still 12 mb and mono is about 11 mb. Is this normal?
Also everytime, I run mono, does it do the same thing it does the first time it was installed and opened?
Sorry, i know nothing about mono but i can tell its definitely optimizing the performance on the g1 though.
great work koushe,
hbguy
Click to expand...
Click to collapse
Koush would know more than I would, but installing mono shouldn't affect everything else on Android. It's not like everything is suddenly using mono instead of dalvik. I suspect you have a strong case of the placebo effect
hbguy said:
I thought this was only a platform for development but its made my g1 much faster and reduced memory from steel and stock browsers as well. My market is still 12 mb and mono is about 11 mb. Is this normal?
Also everytime, I run mono, does it do the same thing it does the first time it was installed and opened?
Sorry, i know nothing about mono but i can tell its definitely optimizing the performance on the g1 though.
great work koushe,
hbguy
Click to expand...
Click to collapse
Yeah, you're just imagining things I haven't even attempted like DEX->CIL yet.
The first APK of Mono is quite large though. I've updated it with a number of bug fixes and also am making it use eglib now. This trimmed the size by a few MB. Getting Mono to work with Bionic might not be possible... (that would trim off another 2MB).
Once again, the APK is just a developers release... something to play with and test.
I have been messing with mono on my G1.
Is it safe to say it will only work with command line apps?
I got my own hello world and a few other things running, but if I try and run any sort of gui I get errors.
Yes, only command line stuff will work. WinForms will not work on Android.
However, you should be able to get OpenGL ES working via PInvoke. I haven't tried it, but it should work just fine.
Koush said:
Yes, only command line stuff will work. WinForms will not work on Android.
Click to expand...
Click to collapse
That is what I thought, I think PInvoke is just a bit out of my skill set.
Thanks for the work none the less.
I got mono building in the Android build environment, and the Mono team accepted a patch to make it work on Android. There's also some changes external to Mono which can be found at the androidmono google code repository:
http://code.google.com/p/androidmono/
First time poster, but long-time lurker and avid Android Developer here.
I'm putting the finishing touches on a tool that decompresses resource files (including the ARSC and any compressed XML files). It's something I sort of took interest in in my spare time, as a learning experience, and I think it would be helpful to the community. It could probably be used to make modifications to compressed layouts in a ROM, such as HTC Sense-based ROMs (decompress the resources, make edits, compress, sign...).
Anyways, I figured I'd ask first... does a tool like this already exist? If so, whatever, this was a learning experience anyways. If not, I'd like to get it out there for all of you geniuses to use.
I'd also like to know what kind of options might be good to have on this tool. Right now it's command-line-based (and might stay that way... I think a UI might be overkill). Let me know. I'll be watching!
That's great!
In which language is it written? Will you open-source it? If so, on which license?
I'm asking cause I need such tool for my Omnipatcher project and I intended to make it myself
Java. I'll probably open-source it once I clean it up enough. I mean, nothing's really a secret in there. I figured out everything I needed from the Android sources.
Brut.all said:
That's great!
In which language is it written? Will you open-source it? If so, on which license?
I'm asking cause I need such tool for my Omnipatcher project and I intended to make it myself
Click to expand...
Click to collapse
When?
When will you relase this?
Oh, good work!!!
Any news?
itanczos said:
Oh, good work!!!
Any news?
Click to expand...
Click to collapse
Sorry guys, I'm really eager to get this out, I'm just struggling to pay the bills, too. I hesitate to make promises, but it should be out sometime this month. I'm just as excited as you probably are to use it. I can't wait to see what kind of themes/mods sprout up once you all get your hands on this.
That sound cool, I was also thinking in creating such a tool or maybe just a shell script that uses aapt to get all the infos and generate an xml out of it but if you already have something in the pipe for doing this... I hope it's finished (or better said at a release stage) soon.
rac2030 said:
That sound cool, I was also thinking in creating such a tool or maybe just a shell script that uses aapt to get all the infos and generate an xml out of it but if you already have something in the pipe for doing this... I hope it's finished (or better said at a release stage) soon.
Click to expand...
Click to collapse
Doesn't aapt only compile the resources, and not the other way around? I didn't think aapt gave us all the information we needed to go back to the original XML.
binarybulge said:
Doesn't aapt only compile the resources, and not the other way around? I didn't think aapt gave us all the information we needed to go back to the original XML.
Click to expand...
Click to collapse
It has dump command and output looks like full XML data just in different (easy to parse) format:
Code:
N: android=http://schemas.android.com/apk/res/android
E: manifest (line=44)
A: android:sharedUserId(0x0101000b)="com.google.android.apps.maps" (Raw: "com.google.android.apps.maps")
A: android:versionCode(0x0101021b)=(type 0x10)0xcf6
A: android:versionName(0x0101021c)="3.3.1" (Raw: "3.3.1")
A: package="com.google.android.apps.maps" (Raw: "com.google.android.apps.maps")
E: uses-sdk (line=54)
A: android:minSdkVersion(0x0101020c)=(type 0x10)0x4
E: uses-permission (line=58)
A: android:name(0x01010003)="android.permission.CALL_PHONE" (Raw: "android.permission.CALL_PHONE")
binarybulge said:
Doesn't aapt only compile the resources, and not the other way around? I didn't think aapt gave us all the information we needed to go back to the original XML.
Click to expand...
Click to collapse
Code:
aapt dump xmltree xxx.apk AndroidManifest.xml
This does output some sort of xml like output... at least as far I have analyzed the output, it should be possible with some parsing code to recover or better said reconstruct a working xml ;-)
Of course, just implementing a complete encoder/decoder would be a nicer solution and as you said, theoretically all the needed framework stuff is on git so it wouldn't be hard to implement it if you have time... I though that this was what you have done or not?
rac2030 said:
Code:
aapt dump xmltree xxx.apk AndroidManifest.xml
This does output some sort of xml like output... at least as far I have analyzed the output, it should be possible with some parsing code to recover or better said reconstruct a working xml ;-)
Of course, just implementing a complete encoder/decoder would be a nicer solution and as you said, theoretically all the needed framework stuff is on git so it wouldn't be hard to implement it if you have time... I though that this was what you have done or not?
Click to expand...
Click to collapse
Haha, yeah it is what I have done. You guys just kind of worried me a little making me think I was reinventing the wheel.
aapt would have been one approach, but I'm still not sure it covers all bases. For example, the strings.xml, arrays.xml, etc files. Those obviously aren't handled the same as layout files. Their contents get compressed into the arsc file. I'm also handling some more complex cases, such as one package referencing drawables from another package.
My goal of course is to restore all input XML, including things like strings.xml, and all of those in various configuration-specific folders (orientation, locales, screen sizes...).
is there any public source of this Compressed Resources (resources.arsc) Decompressor?
i'd like to test it!
Hello Binarybulge!
News?
Is this dead or what?
I'm working on such tool on my own, have managed to decode XMLs (using Android source, not parsing aapt dumps) and now I know, what binarybulge was talking about:
binarybulge said:
aapt would have been one approach, but I'm still not sure it covers all bases. For example, the strings.xml, arrays.xml, etc files. Those obviously aren't handled the same as layout files. Their contents get compressed into the arsc file. I'm also handling some more complex cases, such as one package referencing drawables from another package.
My goal of course is to restore all input XML, including things like strings.xml, and all of those in various configuration-specific folders (orientation, locales, screen sizes...).
Click to expand...
Click to collapse
binarybulge: please, let me know, whether you have quit, don't have time, died or what? Currently I'm working on decoding @ids and /res/values/ and I don't want to reinvent the wheel, if you have done this so far and just don't have time to continue your work.
I'm interested in pitching in. I want an easy tool for decoding a binary .xml file, edit it including adding new elements and then convert it back to binary xml.
I'm pretty familiar with Android low level stuff. One example of my work:
http://forum.xda-developers.com/showthread.php?p=5475283
If I can help in any way, let me know. I don't want to reinvent the wheel either.
jonasl said:
I'm interested in pitching in. I want an easy tool for decoding a binary .xml file, edit it including adding new elements and then convert it back to binary xml.
I'm pretty familiar with Android low level stuff. One example of my work:
http://forum.xda-developers.com/showthread.php?p=5475283
If I can help in any way, let me know. I don't want to reinvent the wheel either.
Click to expand...
Click to collapse
Just for curiosity: how did you do it? Hex edited xml's and resources.arsc?
I'm still working on this tool and have made some progress
Everything that's been done on the keyboard linked above has been done in code. You of all people need no introduction to smail/baksmali
I've rewritten the configuration system (HTC's settings provider is missing in non sense roms), rewritten the parts that interfaces with google voice recognition service and some other tweaks, but it's all code mods.
To fix some remaining issues I must edit xml layouts. Just changing some color code etc. is doable in any hex editor, but adding and removing elements and attributes is kind of hard. I'm stuck at this point and was looking for a tool to convert own xml to binary xml. Since I didn't find such tool I was thinking about creating one and ran into this thread...
I've just successfully and fully automatically decoded all resources for simple HelloWorld apk, then edited them, packaged again using aapt and run on a device It's early alpha and is unusable for now cause it still doesn't support many types of resources, but I have a proof of concept, that it is possible to repackage resources
Brut.all said:
I've just successfully and fully automatically decoded all resources for simple HelloWorld apk, then edited them, packaged again using aapt and run on a device It's early alpha and is unusable for now cause it still doesn't support many types of resources, but I have a proof of concept, that it is possible to repackage resources
Click to expand...
Click to collapse
Yay! Cool! Waiting for release!
Greets!
Hi,
I'm writing an application on android, and for a long time I'm trying to get the lq(link quality) value of an existing bluetooth connection between two mobile phones. I've read on a forum about a method named getLinkQuality() included in
the Bluez API written in C, and I want to include it into my Java code. Does anyone have a similar problem-related example code, like getting RSSI value, any advice or any other idea to get the link quality level? I had troubles using Android NDK so I could really use some help.
Regards,
Peter
Hello, XDA. This is my first post.
Before I start out looking like I'm helpless, and keeping with the mindset that I don't expect something for nothing, I've spent the time to write up newbie-friendly guides:
(edit: Apparently, I have to make eight posts before I can post external links) I will probably accumulate eight posts in this thread, and will edit this at that point.)
Adding OpenVPN and liblzo to the AOSP source tree and compiling a kernel to support it. Includes instructions for patching OpenSSL1.0.0a to enable engine support.
Wrangling with USB permissions
Making a custom boot animation from an animated gif
If it would be better to have the content located on the forum somewhere, tell me where it ought to go.
My problem:
I am trying to roll my own ROM from AOSP (Gingerbread 2.3.4). I have been successfully building images and even kernels for the Nexus S for several weeks now. Recently, I broke something.
I've beat my head against this for three days now. I think I read the entire internet before posting here. I think there is a problem with my build tools, but I don't know where I should be looking for it, or how to test it. The problem is not in the AOSP source tree. I know this because I checked out a clean copy of it, followed Google's instructions, and I get the same result. I get the same result in both the emulator, and on the Nexus S.
When I launch the browser, this is the output from logcat:
(edit: Wow... the parser that tells me I can't post URLs is so aggressive, that I can't paste my logcat output either... I have base64 encoded it instead.)
Code:
SS9BY3Rpdml0eU1hbmFnZXIoICAgNjYpOiBTdGFydCBwcm9jIGNvbS5hbmRyb2lkLmJyb3dzZXIg
Zm9yIGFjdGl2aXR5IGNvbS5hbmRyb2lkLmJyb3dzZXIvLkJyb3dzZXJBY3Rpdml0eTogcGlkPTM1
NyB1aWQ9MTAwMjEgZ2lkcz17MzAwMywgMTAxNX0NCkkvQWN0aXZpdHlUaHJlYWQoICAzNTcpOiBQ
dWIgYnJvd3NlcjogY29tLmFuZHJvaWQuYnJvd3Nlci5Ccm93c2VyUHJvdmlkZXINCkkvQnJvd3Nl
clNldHRpbmdzKCAgMzU3KTogU2VsZWN0ZWQgc2VhcmNoIGVuZ2luZTogQWN0aXZpdHlTZWFyY2hF
bmdpbmV7YW5kcm9pZC5hcHAuU2VhcmNoYWJsZUluZm9ANDA1OTU4Yzh9DQpEL2RhbHZpa3ZtKCAg
MzU3KTogR0NfQ09OQ1VSUkVOVCBmcmVlZCA0NTZLLCA1MSUgZnJlZSAyOTE0Sy81ODMxSywgZXh0
ZXJuYWwgOTM0Sy8xMDM4SywgcGF1c2VkIDVtcyszbXMNClcvZGFsdmlrdm0oICAzNTcpOiBObyBp
bXBsZW1lbnRhdGlvbiBmb3VuZCBmb3IgbmF0aXZlIExhbmRyb2lkL3dlYmtpdC9KV2ViQ29yZUph
dmFCcmlkZ2U7Lm5hdGl2ZUNvbnN0cnVjdG9yICgpVg0KVy9kYWx2aWt2bSggIDM1Nyk6IHRocmVh
ZGlkPTExOiB0aHJlYWQgZXhpdGluZyB3aXRoIHVuY2F1Z2h0IGV4Y2VwdGlvbiAoZ3JvdXA9MHg0
MDAxNTU2MCkNCkUvQW5kcm9pZFJ1bnRpbWUoICAzNTcpOiBGQVRBTCBFWENFUFRJT046IFdlYlZp
ZXdDb3JlVGhyZWFkDQpFL0FuZHJvaWRSdW50aW1lKCAgMzU3KTogamF2YS5sYW5nLlVuc2F0aXNm
aWVkTGlua0Vycm9yOiBuYXRpdmVDb25zdHJ1Y3Rvcg0KRS9BbmRyb2lkUnVudGltZSggIDM1Nyk6
IAlhdCBhbmRyb2lkLndlYmtpdC5KV2ViQ29yZUphdmFCcmlkZ2UubmF0aXZlQ29uc3RydWN0b3Io
TmF0aXZlIE1ldGhvZCkNCkUvQW5kcm9pZFJ1bnRpbWUoICAzNTcpOiAJYXQgYW5kcm9pZC53ZWJr
aXQuSldlYkNvcmVKYXZhQnJpZGdlLjxpbml0PihKV2ViQ29yZUphdmFCcmlkZ2UuamF2YTo2MCkN
CkUvQW5kcm9pZFJ1bnRpbWUoICAzNTcpOiAJYXQgYW5kcm9pZC53ZWJraXQuQnJvd3NlckZyYW1l
Ljxpbml0PihCcm93c2VyRnJhbWUuamF2YToxOTIpDQpFL0FuZHJvaWRSdW50aW1lKCAgMzU3KTog
CWF0IGFuZHJvaWQud2Via2l0LldlYlZpZXdDb3JlLmluaXRpYWxpemUoV2ViVmlld0NvcmUuamF2
YToxOTApDQpFL0FuZHJvaWRSdW50aW1lKCAgMzU3KTogCWF0IGFuZHJvaWQud2Via2l0LldlYlZp
ZXdDb3JlLmFjY2VzcyQ1MDAoV2ViVmlld0NvcmUuamF2YTo1MykNCkUvQW5kcm9pZFJ1bnRpbWUo
ICAzNTcpOiAJYXQgYW5kcm9pZC53ZWJraXQuV2ViVmlld0NvcmUkV2ViQ29yZVRocmVhZCQxLmhh
bmRsZU1lc3NhZ2UoV2ViVmlld0NvcmUuamF2YTo2MTQpDQpFL0FuZHJvaWRSdW50aW1lKCAgMzU3
KTogCWF0IGFuZHJvaWQub3MuSGFuZGxlci5kaXNwYXRjaE1lc3NhZ2UoSGFuZGxlci5qYXZhOjk5
KQ0KRS9BbmRyb2lkUnVudGltZSggIDM1Nyk6IAlhdCBhbmRyb2lkLm9zLkxvb3Blci5sb29wKExv
b3Blci5qYXZhOjEzMCkNCkUvQW5kcm9pZFJ1bnRpbWUoICAzNTcpOiAJYXQgYW5kcm9pZC53ZWJr
aXQuV2ViVmlld0NvcmUkV2ViQ29yZVRocmVhZC5ydW4oV2ViVmlld0NvcmUuamF2YTo2MzMpDQpF
L0FuZHJvaWRSdW50aW1lKCAgMzU3KTogCWF0IGphdmEubGFuZy5UaHJlYWQucnVuKFRocmVhZC5q
YXZhOjEwMTkpDQpXL0FjdGl2aXR5TWFuYWdlciggICA2Nik6ICAgRm9yY2UgZmluaXNoaW5nIGFj
dGl2aXR5IGNvbS5hbmRyb2lkLmJyb3dzZXIvLkJyb3dzZXJBY3Rpdml0eQ0KVy9kYWx2aWt2bSgg
IDM1Nyk6IE5vIGltcGxlbWVudGF0aW9uIGZvdW5kIGZvciBuYXRpdmUgTGFuZHJvaWQvd2Via2l0
L1dlYlZpZXc7Lm5hdGl2ZU1vdmVHZW5lcmF0aW9uICgpSQ0KRC9BbmRyb2lkUnVudGltZSggIDM1
Nyk6IFNodXR0aW5nIGRvd24gVk0NClcvZGFsdmlrdm0oICAzNTcpOiB0aHJlYWRpZD0xOiB0aHJl
YWQgZXhpdGluZyB3aXRoIHVuY2F1Z2h0IGV4Y2VwdGlvbiAoZ3JvdXA9MHg0MDAxNTU2MCkNCkkv
UHJvY2VzcyAoICAzNTcpOiBTZW5kaW5nIHNpZ25hbC4gUElEOiAzNTcgU0lHOiA5
At first, I thought maybe it was some setting specific to the browser. But then I tried another application that also calls native libraries (CSIPSimple). Whenever CSIP tries to load native libraries, I see something like this:
Code:
RC9kYWx2aWt2bSggIDQyOCk6IFRyeWluZyB0byBsb2FkIGxpYiAvZGF0YS9kYXRhL2NvbS5jc2lw
c2ltcGxlL2xpYi9saWJwanNpcGpuaS5zbyAweDQwNTEzNDg4DQpFL1BqU2VydmljZSggIDQyOCk6
IFdlIGhhdmUgYSBwcm9ibGVtIHdpdGggdGhlIGN1cnJlbnQgc3RhY2suLi4uIE5PVCBZRVQgSW1w
bGVtZW50ZWQNCkUvUGpTZXJ2aWNlKCAgNDI4KTogamF2YS5sYW5nLlVuc2F0aXNmaWVkTGlua0Vy
cm9yOiBDYW5ub3QgbG9hZCBsaWJyYXJ5OiByZWxvY19saWJyYXJ5WzEzMTVdOiAgICAzMiBjYW5u
b3QgbG9jYXRlICdfX2Rzb19oYW5kbGUnLi4uDQpFL1BqU2VydmljZSggIDQyOCk6IA0KRS9QalNl
cnZpY2UoICA0MjgpOiAJYXQgamF2YS5sYW5nLlJ1bnRpbWUubG9hZChSdW50aW1lLmphdmE6Mzk0
KQ0KRS9QalNlcnZpY2UoICA0MjgpOiAJYXQgamF2YS5sYW5nLlN5c3RlbS5sb2FkKFN5c3RlbS5q
YXZhOjUzNCkNCkUvUGpTZXJ2aWNlKCAgNDI4KTogCWF0IGNvbS5jc2lwc2ltcGxlLnBqc2lwLlBq
U2lwU2VydmljZS50cnlUb0xvYWRTdGFjayhQalNpcFNlcnZpY2UuamF2YToxMTkpDQpFL1BqU2Vy
dmljZSggIDQyOCk6IAlhdCBjb20uY3NpcHNpbXBsZS5zZXJ2aWNlLlNpcFNlcnZpY2UubG9hZFN0
YWNrKFNpcFNlcnZpY2UuamF2YTo5MTMpDQpFL1BqU2VydmljZSggIDQyOCk6IAlhdCBjb20uY3Np
cHNpbXBsZS5zZXJ2aWNlLlNpcFNlcnZpY2Uub25TdGFydChTaXBTZXJ2aWNlLmphdmE6ODczKQ0K
RS9QalNlcnZpY2UoICA0MjgpOiAJYXQgYW5kcm9pZC5hcHAuU2VydmljZS5vblN0YXJ0Q29tbWFu
ZChTZXJ2aWNlLmphdmE6NDI4KQ0KRS9QalNlcnZpY2UoICA0MjgpOiAJYXQgYW5kcm9pZC5hcHAu
QWN0aXZpdHlUaHJlYWQuaGFuZGxlU2VydmljZUFyZ3MoQWN0aXZpdHlUaHJlYWQuamF2YToyMDM5
KQ0KRS9QalNlcnZpY2UoICA0MjgpOiAJYXQgYW5kcm9pZC5hcHAuQWN0aXZpdHlUaHJlYWQuYWNj
ZXNzJDI4MDAoQWN0aXZpdHlUaHJlYWQuamF2YToxMTcpDQpFL1BqU2VydmljZSggIDQyOCk6IAlh
dCBhbmRyb2lkLmFwcC5BY3Rpdml0eVRocmVhZCRILmhhbmRsZU1lc3NhZ2UoQWN0aXZpdHlUaHJl
YWQuamF2YTo5OTQpDQpFL1BqU2VydmljZSggIDQyOCk6IAlhdCBhbmRyb2lkLm9zLkhhbmRsZXIu
ZGlzcGF0Y2hNZXNzYWdlKEhhbmRsZXIuamF2YTo5OSkNCkUvUGpTZXJ2aWNlKCAgNDI4KTogCWF0
IGFuZHJvaWQub3MuTG9vcGVyLmxvb3AoTG9vcGVyLmphdmE6MTMwKQ0KRS9QalNlcnZpY2UoICA0
MjgpOiAJYXQgYW5kcm9pZC5hcHAuQWN0aXZpdHlUaHJlYWQubWFpbihBY3Rpdml0eVRocmVhZC5q
YXZhOjM2ODMpDQpFL1BqU2VydmljZSggIDQyOCk6IAlhdCBqYXZhLmxhbmcucmVmbGVjdC5NZXRo
b2QuaW52b2tlTmF0aXZlKE5hdGl2ZSBNZXRob2QpDQpFL1BqU2VydmljZSggIDQyOCk6IAlhdCBq
YXZhLmxhbmcucmVmbGVjdC5NZXRob2QuaW52b2tlKE1ldGhvZC5qYXZhOjUwNykNCkUvUGpTZXJ2
aWNlKCAgNDI4KTogCWF0IGNvbS5hbmRyb2lkLmludGVybmFsLm9zLlp5Z290ZUluaXQkTWV0aG9k
QW5kQXJnc0NhbGxlci5ydW4oWnlnb3RlSW5pdC5qYXZhOjgzOSkNCkUvUGpTZXJ2aWNlKCAgNDI4
KTogCWF0IGNvbS5hbmRyb2lkLmludGVybmFsLm9zLlp5Z290ZUluaXQubWFpbihaeWdvdGVJbml0
LmphdmE6NTk3KQ0KRS9QalNlcnZpY2UoICA0MjgpOiAJYXQgZGFsdmlrLnN5c3RlbS5OYXRpdmVT
dGFydC5tYWluKE5hdGl2ZSBNZXRob2Qp
Are there any veteran android devs that can point me in the correct general direction? I don't need to have my hand held, but having never written any app more complex than HelloWorld, I'm not sure where to begin debugging.
edit: As long as I'm thwarting the parser with Base64, here are the external links I am not supposed to be able to post. I hope it helps someone. Figuring all that out was a lot of work.
Code:
W0xJU1RdDQpbKl1bVVJMPSJodHRwOi8vd3d3Lmpvc2hpYW5saW5kc2F5LmNvbS9pbmRleC5waHA/
aWQ9MTEzIl1BZGRpbmcgT3BlblZQTiBhbmQgbGlibHpvIHRvIHRoZSBBT1NQIHNvdXJjZSB0cmVl
IGFuZCBjb21waWxpbmcgYSBrZXJuZWwgdG8gc3VwcG9ydCBpdC4gSW5jbHVkZXMgaW5zdHJ1Y3Rp
b25zIGZvciBwYXRjaGluZyBPcGVuU1NMMS4wLjBhIHRvIGVuYWJsZSBlbmdpbmUgc3VwcG9ydC5b
L1VSTF0NClsqXVtVUkw9Imh0dHA6Ly93d3cuam9zaGlhbmxpbmRzYXkuY29tL2luZGV4LnBocD9p
ZD0xMTIiXVdyYW5nbGluZyB3aXRoIFVTQiBwZXJtaXNzaW9uc1svVVJMXQ0KWypdW1VSTD0iaHR0
cDovL3d3dy5qb3NoaWFubGluZHNheS5jb20vaW5kZXgucGhwP2lkPTExMSJdTWFraW5nIGEgY3Vz
dG9tIGJvb3QgYW5pbWF0aW9uIGZyb20gYW4gYW5pbWF0ZWQgZ2lmWy9VUkxdDQpbL0xJU1Rd
Thanks in advance for any help you are willing to give.
Hi,
I'm trying to work through a hardware detection problem running an app (Osmos, purchased in the Humble bundle for Android). It seems that maybe there's something weird about how my Chinese tablet reports its multitouch or something, I figured I'd just hack the apk to remove the multitouch check and be done with it.
The problem is that the error string isn't in the application itself, it's part of a support library and occurs during initialisation, there's no obvious call to the library to ask for multitouch though I'm sure something flags it as required somewhere along the line but probably in one of a couple of parameter values that are long, undocumented integers.
The support library is called libverde.so and appears in the apk's lib directory when decompiled (apktool, dex2jar, JD are the tools I'm using). There's almost no information about it on the net, only a reference on a pirate site about patching it to remove a check for screen size (similar to what I want to do).
Has anyone heard of this library? Can provide any information on it?
bp.