Database Info

[app] [Think Tank] omnipatcher - patching apps the easy way

This thread is for discussion on how to implement omnipatcher for android.
Project site => http://android-omnipatcher.googlecode.com
Project owner is brut.all
An Android app that can automatically download and apply patches/fixes for installed apps. It makes possible to add features to closed source apps without distributing proprietary code.
Planned features (in more or less chronological order):
* apks patching
o res files adding, deleting, replacing - especially useful for themes designers
o applying smali patches
o bsdiff patching
o xml assets patching
o resources.arsc patching
* signing and zipaligning apks after patching
* automatic app version matching
* automatic downloading to SD card some dependencies like smali, baksmali, zipalign, etc.
* patching system apps
o with root permissions
o without root - by changing package name and installing it beside original app
* possibility to generate update.zip file to reinstall some critical apps
* online repository of users fixes
* tool that simplify or maybe fully automate generating of patches

[Reserved for future use]
[Reserved for future use]

Brut.all said:
I though Java has native zip support?
Click to expand...
Click to collapse
Ok, Metamorph is run from console, so it hasn't got access to Java's zip lib. We wouldn't have this problem.

Brut.all said:
Big, but not huge And so far it was evolving very rapidly
Beside of that it will be iterating project. First we need patcher with some of basic features. Minimalistic UI and configuration, libs and patches will be downloaded manually to SD. Then we will add some automation, new features and so on.
Click to expand...
Click to collapse
Yes, I think an iterative project is the best for this
Brut.all said:
I did it already, this was really esay And file is significantly smaller, because smali/baksmali are built with Maven and hence have doubled deps.
I don't understand... You mean (bak)smaling only needed files? It is possible, I checked it
Click to expand...
Click to collapse
I don't know how exactly baksmali work but I have some idea in mind that I have to check... will tell after reasearching some stuff ;-)
Brut.all said:
I though Java has native zip support?
Click to expand...
Click to collapse
Yes, java has built in support (at least on desktop)

It's very interesting!

I made majority of work needed to release the first version of Omnipatcher with basic functionality and then I took to all Android stuff: UI, etc. 2 days passed and I'm almost at the starting point :-/ I got -10 to Android enthusiasm :-/

Android Layouting is not always that easy :-/
I don't have too much time now because I have to finish my pre bachelor thesis (have final design review on Wednesday) but...
How can I help with it?

Hey -- looking this over, as a non-developer/programmer; I am curious: is there any chance that this program could work to apply patches to *.img files? (Specifically, I'm thinking about hot-swapping the kernel.)

IConrad01 said:
Hey -- looking this over, as a non-developer/programmer; I am curious: is there any chance that this program could work to apply patches to *.img files? (Specifically, I'm thinking about hot-swapping the kernel.)
Click to expand...
Click to collapse
Nope, because the intent of this app is decompiling apk's, patch it and compiling again to make the patching app itself legal because no proprietary content will be distributed... the user has to provide the proprietary app to the patching util.
What you want to do could be easily done with just a binary patcher like bsdiff.

rac2030 said:
Android Layouting is not always that easy :-/
I don't have too much time now because I have to finish my pre bachelor thesis (have final design review on Wednesday) but...
How can I help with it?
Click to expand...
Click to collapse
@brut.all If you want, we could open a wave for Brainstorming on the app and I can help you with the Android app stuff your having problems with?

I'm working on it alone because I write much faster in languages like Java, than in English ;-)
I want to get first basic (root only, sorry), but working version, clean up code, release it, update googlecode site a bit (TODOs in form of issues, some usage docs, etc.) and then I will open to community development. In a few days, I think

Nice, MetaMorph pretty much does alot of this, at least in regards to apk and jar patching. MetaMorph is in the market now. the only problem we have had so far is that market apps require them to be resigned when you edit their contents, so that is problematic.

Yep, someone told me about MetaMorph already, so I checked it out, cause I prefer team work than many parallel projects on the same topic.
However I concluded that MetaMorh has different assumptions: it was created as a theme designers tool mainly, so it emphasizes speed and simplicity.
I want to create all-in-one framework with many methods of patching (simple file replacement, bsdiff, smali, XML patching) and installation (in-place replacement, uninstall & install by package manager, generating update.zip), apk version control and possibility to distribute patches without containing proprietary stuff in them. And hence I have chosen Java in contrast to MetaMorph, which is a shell script.
And you have surprised me by info that MM is in the market. You wrote about MM app here, but you didn't write that you finished it... Is it just a front-end to shell script?

too bad this thread's dead

[THEME TOOL IDEA] Copy 9-patch from original files

While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....

erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Huh. I've been wondering if this was possible. I haven't tried this yet but if it works, nicely done! I think that this would be a huge improvement and addition to the themeporter programs that are out there. There is a high demand for this in that area and in the area of HDPI>MDPI/MDPI>HDPI conversion. I'm certainly bookmarking this!

Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.

Daneshm90 said:
Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.
Click to expand...
Click to collapse
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.

erasmux said:
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.
Click to expand...
Click to collapse
Hmm k i'll spend more time with it, perhaps the resizing program im using causes mishaps. Currently when i resize it completely messes stuff up even though the resolution corresponds to a mdpi device.
I'll do the good ol' trial/error n let u know. Thanks for the (proof of concept)
Edit :
Ok so upon using ur code for transferring images of diff sizes u can obviously tell whts up
So one improvement im thinking off, is if the images differ in size, it could draw the border and eliminate anything outside it. Ugh gotta brush up on my java though :S

bump
10 del al char har

bump
I tested it out and it works great! Thanks!

I really hope someone takes this idea and runs with it! If I knew how to code, I would certainly look into this. Maybe I can get one of the Vibrant Devs to look at this....

erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Can U just tell how to use this code for bulk images?????

pratyush.creed said:
Can U just tell how to use this code for bulk images?????
Click to expand...
Click to collapse
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....

erasmux said:
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....
Click to expand...
Click to collapse
Gr8 work...u made themin a kid's job
Sent from my GT-S5670 using XDA Premium App

???
does the original still work cause im on windows 7 64 bit and i was able to copy the changes to original but not it makes no changes at all, so the original file doesnt get the changes...
please help!!

Need some .Java asssistance [for Tab+]

This can be moved to development if needed.
^prob some Android exp needed as well, but if you're here reading this I assume you have some.^
I am interested in adding an extended power menu, among other things (CRT anim ON if possible, and maybe a few other small ones.)
(yes Im looking at you guys @garyd and @Entropy, j/k you guys work hard enough Im sure.)
While I am reading my intro to Java Programming. I understand Basic programming, Java is what I need to learn. I am also studying .dex in hopes of one day being able to at least edit it.
If anyone would like to help , I have managed to decompile .dex into .jar and from .jar got all the .classes, etc. and then decompiled to .java, which is so much more readable than .smali. ( as it should be)
I have followed the few guides I could find for extended power menu, trying a few different things as I understand all devices are different. flashed and booted, but power button does nothing.
From what I understand it is actually possible to compile .java to .smali to .dex
from what I can gather this involes adding a mReboot:I options to reboot or reboot recovery. Then adding the array to the power menu, then adding the drawable ids and string ids (which I know how to make with apktool).
I saw one thread stating an entry in build.prop ro.mot.deep.sleep.enabled=true was also required.
PM me or reply if interested. I can upload .java files.
--just trying to get some fresh "development options going"
my next book will liekly be the : 6-in-1 building an android app, which I have done with the google App Inventor. It was fun.
*small donation can be made*

.java/.smali help (small donation)

This can be moved to development if needed.
^prob some Android exp needed as well, but if you're here reading this I assume you have some.^
I am interested in adding an extended power menu, among other things (CRT anim ON if possible, and maybe a few other small ones.)
While I am reading my intro to Java Programming. I understand Basic programming, Java is what I need to learn. I am also studying .dex in hopes of one day being able to at least edit it.
If anyone would like to help , I have managed to decompile .dex into .jar and from .jar got all the .classes, etc. and then decompiled to .java, which is so much more readable than .smali. ( as it should be)
I have followed the few guides I could find for extended power menu, trying a few different things as I understand all devices are different. flashed and booted, but power button does nothing.
From what I understand it is actually possible to compile .java to .smali to .dex
from what I can gather this involes adding a mReboot:I options to reboot or reboot recovery. Then adding the array to the power menu, then adding the drawable ids and string ids (which I know how to make with apktool).
I saw one thread stating an entry in build.prop ro.mot.deep.sleep.enabled=true was also required.
PM me or reply if interested. I can upload .java files.
--just trying to get some fresh "development options going"
my next book will liekly be the : 6-in-1 building an android app, which I have done with the google App Inventor. It was fun.
*small donation can be made*

TrueCrypt for Windows on ARM

Because impossible is possible, get TrueCrypt for RT machines here
XDA:DevDB Information
TrueCrypt for Windows on ARM
Version Information
Status: Stable, Retail
Version: TrueCrypt 7.1a
Created 2016-06-26
Last Updated 2016-06-26

Yea! Thanks blob, how you done this? And this will help we to unlock the UEFI? Becouse the option to install an "hidden operating sistem" it's interesting

whats truecrypt supposed to do? what is this tool? oh and welcome back @black_blob :good::good::good:

Wow this is great You sure manage to find some extremely useful bits to bring over. I did notice I had to put a space in the filename for the "TrueCrypt Format.exe" file, since it could not find it otherwise when creating volume. Not sure if it should have a space or if the process spawn should remove the space...
Did you compile this yourself? If so, what toolchain did you use to compile at least the UI portions of this app?
Thanks!

nazoraios said:
Wow this is great You sure manage to find some extremely useful bits to bring over. I did notice I had to put a space in the filename for the "TrueCrypt Format.exe" file, since it could not find it otherwise when creating volume. Not sure if it should have a space or if the process spawn should remove the space...
Did you compile this yourself? If so, what toolchain did you use to compile at least the UI portions of this app?
Thanks!
Click to expand...
Click to collapse
Used MSVC2015, it was just a couple of removing sets to non-writable zones any longer with new headers
Yes, I compiled it myself.

nazoraios said:
Wow this is great You sure manage to find some extremely useful bits to bring over. I did notice I had to put a space in the filename for the "TrueCrypt Format.exe" file, since it could not find it otherwise when creating volume. Not sure if it should have a space or if the process spawn should remove the space...
Did you compile this yourself? If so, what toolchain did you use to compile at least the UI portions of this app?
Thanks!
Click to expand...
Click to collapse
The MSVC project name is Format btw, but TC scripts reference "TrueCrypt Format.exe", so alright, it's a small bug though

Whats the use of this tool?