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
This is probably a noob question, but how can you view the coding of an android application? I just had a small test app developed for me and I would like to look at the "guts" of it.
I downloaded the emulator but I haven't been able to figure out how to see my app's code using it. Maybe there is another way that's easier? You know, something akin to the "view page source" tab enabled in many browsers that allows you to see an html page's code?
I tried opening it with TextEdit on my Mac but it says its not readable.
What's an easy way to take a look at/edit the code?
Thanks in advance for your help!
Android-apktool
Android-apktool - A tool for reengineering Android apk files ...
http: / / code.google.com/p/android-apktool
It is a tool for reengineering 3rd party, closed, binary Android apps. It can decode resources to nearly original form and rebuild them after making some modifications; it makes possible to debug smali code step by step. Also it makes working with app easier because of project-like files structure and automation of some repetitive tasks like building apk, etc.
It is NOT intended for piracy and other non-legal uses. It could be used for localizing, adding some features or support for custom platforms and other GOOD purposes. Just try to be fair with authors of an app, that you use and probably like.
Click to expand...
Click to collapse
Google "apk manager"
Sent from my DROIDX using XDA App
Thank guys, however it says it can't be found - see this screencast I recorded: screencast.com/t/kII8UcBqE1RQ
Any ideas?
I feel like it can't be that complicated, but there is almost no info about in on Google...
Hey Guys,
Recently I was planning to learn to code android apps, so I decompiled an app I wanted to modify & was going through the source code. All of the .smali files were un-encrypted. I would like to know if this code is Objective-C or Java.
I tried to add the code snippets & also tried to pastie it but apparently the posts doesn't seem to accept foreign links so I'll try to post it in the comments.
File Names: h, h$a
Also, I wanted to know what do these file names represent & what does the "dollar" sign stand for in the file names.
Thanks in Advance,
Netguy
Update: I tried posting it via comments but it wasn't possible. Let me know how can I share the code over here. Thanks.
Smali is disassembled Dalvik virtual machine byte code.
The source of it is Java, although you can't easily reconstruct the original source.
MyClass.smali is the class file for MyClass
MyClass$SubClass.smali is the class file for the nested subclass SubClass
MyClass$1.smali is the class file for an anonymous nested subclass.
ab.smali and ab$bd.smali are obfuscated file names.
Some companies rename everything using automatic tools to hide the intent.
Yes, you can write in smali if you like.
Usually such use is limited to small changes in an existing program.
Thanks a lot for the information Renate NST. While digging through some of the smali files, I found some URLs related to the google ads. So will changing the URL to something else disable the ads or will it just result in malfunctioning of the app ? Thanks a lot once again.
I'm recently trying to edit my framework with this mod
http://forum.xda-developers.com/showthread.php?t=1916094
Well actually the steps in that thread are very simple, but since I'm trying to apply that to my Xperia Ray so it must have slightly different steps
What I want to ask :
- In framework/res, I found drawable-.........( mdpi,hdmpi,ldpi,etc.). If I'm going to replace the .9png's picture in there, should I make the picture as same as the original picture dimension? I'm using Dev-Drawable app in the Play Store ( it makes picture to drawable- hdpi,mdpi,etc. ), the result of using it is it gives me the mdpi version of the picture but with different dimesion from the original picture.
- I found errors and it says that I have errors in the /res/values/public.xml
I found this :
Code:
Don't do that! :) I think I should explain the purpose of public.xml file in the project wiki, because many people are confused. Note that you don't need this file when you build an apk from sources and apktool building mechanisms are very similar, so guess what: you could remove this file from decoded application and apktool will rebuild it without any problems. I had a reason why to generate public.xml - it's a feature, not a bug! ;)
Well, the reason is: there may be references to resources in the application code. If resources ids will change after build, then code will reference different resources than in original apk. public.xml file gives us sureness that resources will get same ids after build - it's the only one reason to use this file. And you want to manually modify these ids ;)
Adding or removing new resources is somewhat tricky. Yeah, I should write about that in the wiki.
You could remove any line from public.xml (even making a "hole" in the ids) at any moment, but you must be sure, that resource isn't referenced in the code.
There is never much sense in modifying ids in public.xml, because then modified lines lose their purpose.
If you want to add new resources, e.g. drawables and use them in the XML files you don't have to change anything in the public.xml file.
If you want to add new resources and use them in your code, then you have to add them into public.xml, because you need to reference them somehow. Or you could use Resources.getIdentifier() method, but this is ugly.
And now the most tricky part: if you want to remove some resources, you have to remove info about them from public.xml as well. So first you have to be sure that they aren't referenced in the code. But there is also this "hole" problem, so:
If these resources are at the end of ids stack, then there is no problem.
If resources are near the end of ids stack and you are sure, that all resources after them aren't referenced in the code as well, then you could just remove them all. Actually you have did virtually the same, cause after modifying ids you made these lines totally useless, you broke them, so you could just remove them.
If you want to remove some resources, but add same or greater quantity of new ones (of the same type), then there is no problem - new resources will automatically fill in "holes" in ids. You don't have to add them to public.xml .
If none of above conditions are met, then you have holes and you have to fill them by something. But you don't have to add "useless .pngs" - just add:
Code:
<item type="drawable" name="DUMMY1" />
<item type="drawable" name="DUMMY2" />
<item type="drawable" name="DUMMY3" />
...
Like above, you don't have to add these resources to the public.xml .
And because I'm a newbie I don't really get what that mean. So I just delete the files that I'm going to replace and I can re-compile the framework, but I got bootloop, LOL.
I confused about :
1."You could remove any line from public.xml (even making a "hole" in the ids) at any moment, but you must be sure, that resource isn't referenced in the code."
What are the "holes" and " referenced in the code" mean?
2. Because I want to add .png's picture to the drawable-mdpi folder, Do I need to add dummies to the public.xml ?
3. I'm using the tricky signing method ( open archive in the original framework, copy meta-inf & android manifest and replace those files to the modded framework). Is this cause me an error?
Help me mateee:crying:
anyone???
Hello All,
I have an application that I want to add some features to in the form of an additional activity. I have decompiled it with APK tool and attempted to add my own smali files (from the decompiled 2nd app that I developed). I immediately run into problems with the dependencies of my app being different than those of the original app. For example, my app uses the google Easy Permissions lib to ask for permissions. What is the right strategy to help de-conflict the res/values/*.xml files between two apps that both have their own resources? Are there any tools that can assist in this? What about layout and drawable resources?
I started writing a python script to merge public.xml and the others, re-map the ID's for those resources, and then search the smali files to change the values there. That seems error-prone, and I am not even sure if that is the right thing to do.
I had a second thought that perhaps aapt2 compilation of resources could perhaps be modified to give me a different package ID for the app I created and control source to (such as 0x80... instea of 0x7f...) but I am not sure exactly how to go about that, or if that would even work either
Any advice or tools I should be looking at?