[SIZE=-2][ I realize this post doesn't belong here - shout me down after you've read the post ][/SIZE]
[gratuitous-begging]
Hi folks,
If you are publishing ROMs or other installable .ZIPs please please please (yes, I'm begging now) publish MD5 checksums (or at least an exact byte count) of the files you upload for public consumption in the posts in which they are announced. Both would be even better.
The problem isn't one of authenticity of download files (although it is useful to have that); it's that a tremendous amount of "help me" board traffic gets generated (both here and at AF) by folks complaining that they have a problem installing a ROM, when the real trouble they are having is corrupted files. I would be willing to bet that more than 90% of this traffic is caused by people attempting to flash truncated or otherwise corrupted files.
Yes, I know - if they would just pay attention to the fact that "E:" means ERROR in Amon_RA output, we would all be better off. That's hoping for a lot from newbs, though.
But honestly, if you don't publish a byte count or a checksum, those folks can't really check their downloads, even when they do know better. ( Some of the download sites report the download size, but usually only to 3 or 4 significant figures, and with no clear indication of whether MB means 10^6 or 1024^2. )
Many of the devs don't spend much time in the XDA Q&A or General sub-forums, and possibly never on AF, so they don't see this going on; that is to be expected and OK, too, because they are busy building ROMs and other goodies.
But, you can help the folks that are helping other folks get rooted in order to enjoy your work product if we can encourage a culture where people routinely check their downloads - using their phone! - to make sure that your good stuff has arrived safely on their SD cards.
With the help of jcase and Eclips3, user "scary alien" from AF put together a free app for computing MD5 or SHA1 checksums on the phone. There are lots of other ways to skin that cat, too; but the place to start encouraging a culture of having people check their downloads is with the devs - at their announcement posts.
Thanks for your time and consideration.
[/gratuitous-begging]
bftb0
good idea. would help those who have corrupted downloads.
bftb0,
Wonderful thread / post. Thank you very much--this is much appreciated.
By the way, I am working on trying to make the MD5 sum app a little more user-friendly by making the file selectable instead of having to type in the filename (I'm still learning about Android app development......thanks again to jcase and eclips3 for getting me started). I'll try to re-post here when (if?) I ever get this enhancement made.
We all very much appreciate all of the hard work and fruits of labor that you developers produce. Thank you!
scary alien said:
bftb0,
Wonderful thread / post. Thank you very much--this is much appreciated.
By the way, I am working on trying to make the MD5 sum app a little more user-friendly by making the file selectable instead of having to type in the filename (I'm still learning about Android app development......thanks again to jcase and eclips3 for getting me started). I'll try to re-post here when (if?) I ever get this enhancement made.
We all very much appreciate all of the hard work and fruits of labor that you developers produce. Thank you!
Click to expand...
Click to collapse
You might consider putting the byte count in the result display along with the checksum; if you get those two mods put together, you should make an XDA-wide announcement as something this generic is useful to all XDA (Android) users. Take it one step further - and add a "ROM verify (only)" function, and everyone at XDA will know your (screen) name.
Jp50 -
Check out this tangentially related thread. I wonder if your problem the other day with Nonsensikal was due to a similar problem - corruption of the ROM not on the SD, but in system flash (NAND).
One more tidbit, I suppose I should come clean about, it seems about time.
bftb0 == erisuser1 (on AF)
That should explain my motivation for begging this way. Just a historical accident that it worked out that way - i tried not to let the two become cross-forum sockpuppets, but sometimes that was inevitable
bftb0/eu1
Sheer elegance... I should have known it was you eu1!
Great post.
bftb0 said:
You might consider putting the byte count in the result display along with the checksum; if you get those two mods put together, you should make an XDA-wide announcement as something this generic is useful to all XDA (Android) users. Take it one step further - and add a "ROM verify (only)" function, and everyone at XDA will know your (screen) name.
Click to expand...
Click to collapse
eu1/bftb0, lol! I am floored! But not too shocked...how do you find the time?
The byte-count (shown as "File Size:") is already present...I actually created this app in no small part of your exhortations for checking MD5s over at AF -- I knew better than to not include something so vital per your tutelage.
Also, for those that don't know, you can also check your MD5 checksums via Astro File Manager (long-press a filename and select Details). There is also a free app in the Market, ManD5 that will also compute MD5 sums (it did not work (at least for me) when I first wrote my little app, but it does now). And, of course, in some ROMs, the busybox/md5sum program is often available.
However, mine will also calculate SHA1 checksums (which do take much longer to calculate and are more compute-intensive).
Cheers everyone!
This should get stickied or something. We should also get in the habit of asking devs for MD5s if they don't provide them initially. I think you're right; a massive amount of traffic (and headaches!) could be spared if we would do this.
I will provide md5's for future releases I have no problem with posting them but I think the expectation that this will somehow reduce the number of newbie questions/issues is unrealistic. The fact of the matter is that people just don't take the time to read/understand what it is that they are doing. I appreciate the effort here but I just don't see it making a difference. You love my rants don't you? lol
We'll see
Sent from my nonsensikal froyo
listyb01 said:
I will provide md5's for future releases I have no problem with posting them but I think the expectation that this will somehow reduce the number of newbie questions/issues is unrealistic. The fact of the matter is that people just don't take the time to read/understand what it is that they are doing. I appreciate the effort here but I just don't see it making a difference. You love my rants don't you? lol
We'll see
Sent from my nonsensikal froyo
Click to expand...
Click to collapse
yeah i agree here....even though grdlock site where i upload my roms automatically displays the md5sum i just doubt that people who won't even use the search function will bother to check the md5
listyb01 said:
The fact of the matter is that people just don't take the time to read/understand what it is that they are doing. I appreciate the effort here but I just don't see it making a difference.
Click to expand...
Click to collapse
That's probably correct, but you will be reducing the effort of the folks that are trying to help the newbs out, and know better.
Right now what they have to do - in addition to instructing the newb where to get an app that will report file size or md5sum for a ROM file is to: download the ROM themselves, run it through "jarsigner --verify" to see if their own download is OK (signing check), and then compute the MD5 and report that back to the newb. It would be a lot easier to just say:
"Use Astro to compare the MD5 signature of the file on your SD card to what the dev published".
In addition, it helps a little bit with the authenticity problem, too - if someone finds a file on a mirror someplace, they can go back and check the dev's post to gain some confidence what they found is actually "the real deal". Right now that's an impossibility with some dev ROMs.
cheers,
bftb0
bftb0 said:
That's probably correct, but you will be reducing the effort of the folks that are trying to help the newbs out, and know better.
Right now what they have to do - in addition to instructing the newb where to get an app that will report file size or md5sum for a ROM file is to: download the ROM themselves, run it through "jarsigner --verify" to see if their own download is OK (signing check), and then compute the MD5 and report that back to the newb. It would be a lot easier to just say:
"Use Astro to compare the MD5 signature of the file on your SD card to what the dev published".
In addition, it helps a little bit with the authenticity problem, too - if someone finds a file on a mirror someplace, they can go back and check the dev's post to gain some confidence what they found is actually "the real deal". Right now that's an impossibility with some dev ROMs.
cheers,
bftb0
Click to expand...
Click to collapse
I see the value here.
Man I need to get out more, didn't really realize that this was such a hot topic Now back to building v5.3 with md5
Sent from my nonsensikal froyo
listyb01 said:
I see the value here.
Man I need to get out more, didn't really realize that this was such a hot topic Now back to building v5.3 with md5
Click to expand...
Click to collapse
\m/
It's probably just a hot topic to me. You wouldn't believe how hard it is sometime to extract diagnostic information from a newb
:|
bftb0 said:
\m/
It's probably just a hot topic to me. You wouldn't believe how hard it is sometime to extract diagnostic information from a newb
:|
Click to expand...
Click to collapse
...but you're good at it.
As a semi-noob - perhaps the noobs would get more benefit if there were some instructions on what to do with the md5 on the rom page. The developer could use the instructions of his choice and the noob would follow them blindly as long as they're detailed enough. It could be a little tack on at the end of the disclaimer (or wherever they wana put it).
Sent from my Froyo Eris using XDA App
bftb0 said:
...Take it one step further - and add a "ROM verify (only)" function...
Click to expand...
Click to collapse
You mean something like recognizing when a ROM (.zip) name is entered or selected and calculating its MD5 sum and file size against a known, published value?
This would be pretty straightforward (I think...). I could initially just keep an internal table of the ROM names/size/MD5 sums and later, try to acquire this info dynamically from some public source...
Am I in the ballpark here?
Thanks!
edit: would the "jarsigner --verify" method be available to me in my app? (or is that what you had in mind all along?)
scary alien said:
edit: would the "jarsigner --verify" method be available to me in my app? (or is that what you had in mind all along?)
Click to expand...
Click to collapse
Exactly that functionality (but obviously not any Sun/Oracle code). What I don't know off the top of my head is whether or not the Google API provides sufficient functionality to implement it without resorting to a native method. That would make it more portable to other devices (if it is possible).
The native code for doing all the un-.zipping, and signing checks is in the AOSP sources (and elsewhere, e.g. CyanogenMod, Clockwork) available through github etc. From there it is only a "simple matter of programming"
bftb0
Okay, I think I'm fairly close...would you consider the verifying the SHA1 digests from the META-INF/MANIFEST.MF file against each file in the .jar/.zip as "verification"?
I'm a little shaky on the certificates and such, but I think I can do the validation of each file listed in the MANIFEST.MF file. There is the matter of the CERT.SF file whose checksums I can't (yet ) match-up with anything...
Thoughts?
scary alien said:
Okay, I think I'm fairly close...would you consider the verifying the SHA1 digests from the META-INF/MANIFEST.MF file against each file in the .jar/.zip as "verification"?
Click to expand...
Click to collapse
Okay, yeah, its probably silly to quote yourself p), but I've got Java code that works. It reads a .jar file, inspects the MANIFEST.MF file, and calculates the SHA1 digest for each file listed in the manifest. Still gotta incorporate it into my app, but should be pretty straight-forward to do...(oh, and convert the hex SHA1 sums into base64, but my app is already coded to do that).
Stay tuned...(hopefully by tomorrow night)
Here's a test run of my code against Zanfur's overclock patch jar file and the fciv-generated SHA1 digests for the extracted directory:
Code:
d:\temp >[COLOR="blue"][B]java JarVerify kernel-overclock-update-v3.zip[/B][/COLOR]
jar file = d:\temp\kernel-overclock-update-v3.zip
File: [B]boot.img [/B][SHA1 base64 checksum: t4mIp5wAG9kIwTVE+I07BUBFtDE=]
SHA1 (hex) checksum: [COLOR="Red"]b78988a79c001bd908c13544f88d3b054045b431[/COLOR]
SHA1 (base64) checksum: t4mIp5wAG9kIwTVE+I07BUBFtDE= (from MANIFEST.MF)
File: META-INF/com/google/android/[B]update-script [/B][SHA1 base64 checksum: nyfFfx8UMymvIfBVT/6M6stjyjs=]
SHA1 (hex) checksum: [COLOR="red"]9f27c57f1f143329af21f0554ffe8ceacb63ca3b[/COLOR]
SHA1 (base64) checksum: nyfFfx8UMymvIfBVT/6M6stjyjs= (from MANIFEST.MF)
File: system/lib/modules/[B]wlan.ko [/B][SHA1 base64 checksum: WwY9Y+I3ziLsQMDfr6S3wmGn2bs=]
SHA1 (hex) checksum: [COLOR="red"]5b063d63e237ce22ec40c0dfafa4b7c261a7d9bb[/COLOR]
SHA1 (base64) checksum: WwY9Y+I3ziLsQMDfr6S3wmGn2bs= (from MANIFEST.MF)
d:\temp>[COLOR="Blue"][B]fciv -r -sha1 "d:\temp\kernel-overclock-update-v3"[/B][/COLOR]//
// File Checksum Integrity Verifier version 2.05.
//
Start Time: 09/08/2010 at 23h54'34''
[COLOR="red"]b78988a79c001bd908c13544f88d3b054045b431 [/COLOR]d:\temp\kernel-overclock-update-v3\[B]boot.img[/B]
1a93b9f8dc0e3a7db4d62e1c28e34e377ab59a53 d:\temp\kernel-overclock-update-v3\META-INF\CERT.RSA
9d109bf59721f29b2e6ed90780e1e98e5aa6bf1a d:\temp\kernel-overclock-update-v3\META-INF\CERT.SF
[COLOR="red"]9f27c57f1f143329af21f0554ffe8ceacb63ca3b [/COLOR]d:\temp\kernel-overclock-update-v3\META-INF\com\google\android\[B]update-script[/B]
0e6fdf73ab53327c944a9430b090e388f76b60a1 d:\temp\kernel-overclock-update-v3\META-INF\MANIFEST.MF
[COLOR="red"]5b063d63e237ce22ec40c0dfafa4b7c261a7d9bb [/COLOR]d:\temp\kernel-overclock-update-v3\system\lib\modules\[B]wlan.ko[/B]
End Time..: 09/08/2010 at 23h54'34''
Processed 8 directories
Processed 6 files
Errors have been reported to fciv.err
d:\temp>
Its coming!!! (probably not tonight, though )....I've got my MD5sum app coded with the ability to verify all of the SHA1 checksums in a jar file's MANIFEST.MF.
I've gotta cleanup some code and make the interface invoke the jar verification as a separate option from the ones currently available.
Interesting things I've found while testing and doing some research:
1. There are usually two phases to a "jarsigner.exe -verify". Certificate verification and MANIFEST file checksum verification. It appears that -verify does not cause/force certificate validation. The second phase is pretty much does what my app does/will do: scan through the manifest and validate the manifest's entry's SHA1 digests. My app will initially not check certificates--just the individual manifest's digest verification.
2. The Eris 2.1 leaks ROMs (base root and the three non-root leaks) are not jars per se: they do not contain a META-INF directory and therefore there is no MANIFEST.MF to scan. Only a filesize and checksum verification is apparently needed or used on these PB00IMG.zip files.
3. I successfully verified Ivan's 1.0 ROM (100MB) on my Droid X...it took around 3 minutes (will obviously take longer on the Eris...).
Here's a ddms trace of my app scanning the same kernal-overclock-update-v3.zip (renamed to koc.zip to make typing it in easier/quicker):
Code:
09-09 23:31:35.302: INFO/MD5sum(5191): jar file = /sdcard/download/koc.zip
09-09 23:31:35.302: INFO/MD5sum(5191): File: system/lib/modules/wlan.ko [base64 SHA1: WwY9Y+I3ziLsQMDfr6S3wmGn2bs=]...verifying checksum...
09-09 23:31:36.029: INFO/MD5sum(5191): SHA1 (hex) checksum: 5b063d63e237ce22ec40c0dfafa4b7c261a7d9bb
09-09 23:31:36.029: INFO/MD5sum(5191): SHA1 (base64) checksum: WwY9Y+I3ziLsQMDfr6S3wmGn2bs= (from MANIFEST.MF)
09-09 23:31:36.029: INFO/MD5sum(5191): SHA1 (base64) checksum: WwY9Y+I3ziLsQMDfr6S3wmGn2bs= (calculated)
09-09 23:31:36.037: INFO/MD5sum(5191): SHA1 checksum matches MANIFEST.MF (w00t)
09-09 23:31:36.037: INFO/MD5sum(5191): File: boot.img [base64 SHA1: t4mIp5wAG9kIwTVE+I07BUBFtDE=]...verifying checksum...
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 (hex) checksum: b78988a79c001bd908c13544f88d3b054045b431
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 (base64) checksum: t4mIp5wAG9kIwTVE+I07BUBFtDE= (from MANIFEST.MF)
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 (base64) checksum: t4mIp5wAG9kIwTVE+I07BUBFtDE= (calculated)
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 checksum matches MANIFEST.MF (w00t)
09-09 23:31:38.091: INFO/MD5sum(5191): File: META-INF/com/google/android/update-script [base64 SHA1: nyfFfx8UMymvIfBVT/6M6stjyjs=]...verifying checksum...
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 (hex) checksum: 9f27c57f1f143329af21f0554ffe8ceacb63ca3b
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 (base64) checksum: nyfFfx8UMymvIfBVT/6M6stjyjs= (from MANIFEST.MF)
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 (base64) checksum: nyfFfx8UMymvIfBVT/6M6stjyjs= (calculated)
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 checksum matches MANIFEST.MF (w00t)
Cheers!
Ill publish these and make a sticky about it with detailed instructions on how's to check an MD5. If someone could PM me the list that would be a big help.
Cheers!
Ck
Sent from my Droid using XDA App
Captainkrtek said:
Ill publish these and make a sticky about it with detailed instructions on how's to check an MD5. If someone could PM me the list that would be a big help.
Cheers!
Ck
Sent from my Droid using XDA App
Click to expand...
Click to collapse
Captainkrtek,
bftb0 / eu1 included a link to a thread I created on AF (http://androidforums.com/htc-droid-eris/138831-verify-your-files-md5-checksums.html) in the OP (http://forum.xda-developers.com/showpost.php?p=7919706&postcount=1) that details various ways to check a file's MD5s checksums. Version 1.0 of my app simply calculated MD5 or SHA1 checksums against a specified file. There are several easy ways to get MD5s on the phone itself, as I detailed in the thread on AF.
Via bftb0/eu1's idea/suggestion, I'm very close to releasing an update to the app (v2.0) I wrote that will essentially do a 'jarsigner -verify' function against a jar (custom ROM)--at least the verification of the SHA1 digests of the files listed in the jar's manifest. This should take the guesswork out of knowing whether or not a user has successfully downloaded a complete/uncorrupted custom ROM (or otherwise signed jar file).
Last weekend, I posted a thread (http://androidforums.com/eris-all-things-root/168942-phone-rom-checksum-verifier.html) re. v1.1 of my app that was basically a brute-force approach to ROM verification. I created a table that the app loaded and compared against the checksum of the specified file to check its validity.
Anyway, I'm hunkering-down this evening trying to finish what my last two posts have detailed re. the v2.0 version of my app. My biggest hurdle is my unfamiliarity with Android development ))...I want to make it more user-friendly by not requring that the filename be inputed by hand, but instead allowing a file to be selected. I got just a little bit more testing and verification to do.
I'll be soliciting feedback and folks to test the app out and let me know what they think.
Thanks and cheers!
In preparation for the upcoming Cyanogenmod wimax love, here are steps you can take to ensure you have valid and sane RSA keys on your device.
This article assumes you are not a complete Android / Linux newb. Please note that I wasn't the one who discovered the RSA keys in /dev/mtd/mtd0... I am only building on the work of others.
If the parts in red aren't true... chances are you destroyed your unique RSA keys.. if you don't have a backup you will not be having wimax on your evo.
On your EVO via the adb shell console:
Take the output of the commands below and save each to your Linux desktop (including the === BEGIN/END XXXX === parts!)
Get your RSA private key ( id_wimax.rsa)
sed -n '/BEGIN RSA/,/END RSA/p' /dev/mtd/mtd0
Get the certificate your device signed ( unknown.crt):
sed -n '/BEGIN CERT/,/END CERT/p' /dev/mtd/mtd0
On your Linux desktop:
With the information above:
have openssl generate an md5 for the RSA private key:
openssl rsa -noout -modulus -in id_wimax.rsa | openssl md5have openssl generate an md5 for the CERT:
openssl x509 -noout -modulus -in unknown.crt | openssl md5
If the hashes above match, the rsa key signed the crt (which is good)
Examine the crt to make sure it's correct...
openssl x509 -noout -text -in unknown.crt
.
Subject: C=TW, O=HTC Corporation, OU=WiMAX Forum(R) Devices, CN=38E7XXXXXXXX
.
CN (Common Name) should *exactly* match the WiMAX MAC address of your EVO.
You can find where I originally posted this here:
http://groups.google.com/group/wimax-hacking/msg/d019503a1898a9e3
Good luck!
P.S. It also looks like everyone will lose WiMAX connectivity on their EVO's at May 26 23:59:59 2030 GMT
For the super noobs, to execute it:
cmd
adb shell ( then you'll get # )
sed -n '/BEGIN RSA/,/END RSA/p' /dev/mtd/mtd0
Give it a few seconds and you'll see 20-30 lines of RSA code.
If you want to save them ( not sure why, but why not? ) click on the top left cmd icon, then goto edit select all, then edit copy then goto note pad and paste it. then when you save that notepad with your keys in it, change the save encoding to Unicode. It should be near the right bottom, near the save button.
Thanks man. we can add this to the RSA/4G verification arsenal.
Although the ADB commands will work on a windows machine, I'm guessing the verifications till requires the linux desktop?
hecklbrg said:
Although the ADB commands will work on a windows machine, I'm guessing the verifications till requires the linux desktop?
Click to expand...
Click to collapse
I did mine on a windows machine.. was it supposed to spit out a long code? Or was it just encrypted because I did it on windows and now linux?
I have cygwin on my laptop, and cygwin was able to validate the md5 sum as it includes openssl.
I am running cm6.1.1 so I had to check the box for my phone to fully validate the rsa cert.
Swyped on my PC36100 using tapatalk!
And for Super Duper Noobs
This guide assumes you have 4G in your area
1. Flash stock evo sense rom
2. Turn on WiMax radio
3. Await connection to 4G
4. If 4G connects your good. If not, then i'm sorry for you.
Excellent post...
Swyped from my EVO
You can also just download openssl compiled for windows. Works perfectly fine.
Now, the big question is, if we have the RSA key and the CERT is there a way to put them back if we mess things us? I know we can do a nandroid, I'm mostly just curious. The more methods you use to back up your stuff and the more places you put those backups the better imo
Hi all -
Apologies if this is a stupid question. I'm trying to create an app that has the protected 2 level DEVICE_POWER permission. Is this possible without having a full-blown Custom ROM?
Things that I have tried:
1) Move apk from data/app to system/app [in packages.xml the app is then classified as system="true" but isn't allowed to get the permission]
2) In packages.xml, manually hack the certs line to be the same as a system app that does have the DEVICE_POWER permission
3) try to hack the file in /system/etc/permissions to add another gid to DEVICE_POWER or the uid of the app that I'm running
4) tried to re-sign the framework-res.apk and the other other system apk's with the same cert with the AOSP platform key [although google does seem to sign some apps with that key, B&N seems to have done the "right" thing and not signed everything with the platform key]. Just gets caught in a bootloop
In the devicemanager.db under /data/data/com.android.providers.settings/databases, in the registry table, it does show the hash of the system's private key ... wasn't sure if I could do anything with that though.
Someone created a custom screensaver that puts the cover of the book you're reading as screensaver and modified the Settings.apk to do so. I don't quite get how he was able to do that and still have the signature remain intact?
Thanks for the help!
AFAIK you have to build a custom ROM to do this.
Yeah I think so too, apps wanting that permission need to be signed with the platform key afaik.
This patch is against framework.jar for Android 4.4 (KRT16M) and allows you to modify system packages without them being verified.
Why would you want this?
Re-signing isn't possible with many google packages as they check their own certificates at runtime (GooglePlayServices). This patch allows you to make any modifications you like to system packages, while keeping the original certificates.
Isn't it unsafe to not verify packages?
Yes. However, this patch only applies to system packages. Those downloaded from the market are still verified as usual. The /system filesystem is read-only by default. The only way for a package to be infected is if an application has root privileges (via SuperSU or similar). Of course you should assume that after giving an application elevated privileges it could infect packages with or without this patch.
How does it work?
Packages in android are loaded by PackageParser. The method collectCertificates attempts to read the file AndroidManifest.xml from system packages, which causes the underlying JarFile to verify it against the embedded signature. If everything was successful it returns the certificate. This patch changes collectCertificates to load and return the certificate directly, without trying to read AndroidManifest.xml.
You must delete META-INF/CERT.SF and META-INF/MANIFEST.MF from any package you modify. This patch doesn't change the underlying JarFile code, which by default uses those files to check entries as they're read from the archive. You should leave META-INF/CERT.RSA alone as that's the certificate this patch loads.
The patch was produced against framework.jar from the factory image KRT16M using baksmali v2.0 .
SHA1
Code:
433eeec32008015a1f54964bf036f4eaddb3864b framework-jar-KRT16M-raw-certificates.patch
75b5999203f355cf45387a424246e988440c3068 framework.jar
*reserved*
Thanks for this great mod.. Modify system packages works but when add new apk system (like sony apps to my CM 11 device), ktkat won't accept as app installed, even when I don't modify anything in apk.
Sent from my Xperia Mini Pro using Tapatalk