yashsingh1/xdaforums huggingface dataset:
[LG Optimus 2x] Keithn:
Thanks, as you said I just didn't have patch installed. And for ubuntu " sudo apt-get install patch" will do it. The difference is that sudo just runs the command as root rather than running the terminal in root if you get what I mean.

I got the patch to work, I think, I'll give it a try soon.
[LG Optimus 2x] pastime1971:
you ran it w/ cm9 option, but isn't your ROM based on stock ?

could you try specify aosp instead of cm9 ?

edit: from the look of that thread, your ROM is cooked from stock ROM, not compiled, right ?
[LG Optimus 2x] c-pimp:
activitymanager

@pasttime1971 here are the activitymanager files from the newest gummy build

incase i dont finish or i mess up i put them up for you to take a look at pasttime...

edit: Im having trouble with the activitymanager and instructions you gave me, im still trying but im starting over again and trying it again....

since this build is supposed to be built from AOSP source with some cherry picks from aokp and cm and has the zygote part should I try using the cm frameworks.diff and see what happens with that? might that work?

@mateorod

do I need to dig some specific files out of my crespo build that you need to look at?
[LG Optimus 2x] c-pimp:
success

okay since the zygote part was missing and whatnot, I decided to make a copy of my gummy source directory, repo synced, applied the aosp patches for build.diff and libcore.diff and applied the cm9 patch to the frameworks.diff and everything succeeded and nothing failed... building now to test this out.
[LG Optimus 2x] mateorod:
Good plan, c-pimp, I hope it works for you.

As far as crespo goes, it seems that the services and framework jars you had zipped up from the crespo builds were identical, so in one of those two zip packs the files got mixed up somehow.

Either that or the patching failed, but I kind of doubt that as the core.jar was patched successfully.

Try digging them out of the original builds again if you have them and we'll try again.
[LG Optimus 2x] c-pimp:
Ok I will rebuild the crespo files again and see what happens :-)
[LG Optimus 2x] c-pimp:
crespo

here is crespo files

i rebuilt and have not had a chance to look at them and have to get to bed, I will look at it more in the morning and follow your instructions and try to make a patch like you said!

here they are if you want to look at them

hopefully these are correct, if not ill figure it out tomorrow and see what went wrong, everything looks to patch and build fine
[LG Optimus 2x] ido:
I get the same error when patching asop.

And yes, the rom is based on stock i9100 ICS
[LG Optimus 2x] c-pimp:
Gummy files are done and will be posted tonight as well :-) used cm9 for frameworks..jar used the aosp for for the other two
[LG Optimus 2x] mateorod:
Are you saying that you used the aosp patches on the services and core, and then manually tried the cm9 patch on the frameworks? I am glad that worked for many reasons!

I tried the mix and match on one of JoeSyr's ROMs when he very first posted them, but it didn't work. But I have been wondering about this method for a long while. Since there are really only three base roms just about every other rom is made from, I think we just about have to have all the patches we could need, once the crespo patches get finished (maybe 15 mins).

pastime, it will be a bit of trial and error for the user, but maybe we could add an incremental patching option, where if selected, some of these homebrewed combo roms users could do this through the patcher.

As in, they select incremental through the patcher, and then when it gets to framework, they select a patch and try it, then have the option to try another type of patch if it fails.

We'd need to have the option to try again on hunk failure and also have the patch output simultaneously logged and displayed in the terminal, both of which I think would be for the best anyway.

Good work c-pimp!

UPDATE: Crespo patches succesfully created and in the Dropbox in a folder titled crespo5-23.
[LG Optimus 2x] c-pimp:
Yes I did use the aosp diff and when I got to frame work I used the cm9 diff.. It applied fine but I have yet to test if it boots properly... More details later :-)

I'll have to try the crespo again now that it worked properly this time and see if it works for slim
[LG Optimus 2x] c-pimp:
sorry guys, had to put the dog down today... no time to be on the computer cept this quick login...

here are the gummy files for 1.2, id like to try to patch them myself but tonight I just dont have it in me or the time...

talk to you guys tomorrow ...
[LG Optimus 2x] Lanchon:
silly question:

regarding the latest smali patcher (alpha v0.4.3 patches 2012.05.18.), how do i know against what version of a particular rom (say cm9) were the included patches made?

im trying several cm9 nightlies but they always end up in some "already applied patch" being detected. i can accept relocated hunks, but i won't trust the resulting binary if hunks were ignored.
[LG Optimus 2x] mateorod:
I made these patches from a ROM that was for encore, if I remember correctly. One ROM can be made differently from another in that certain hardware (say 3G,4G or no phone; camera or no camera) is supported on one and not another. With each comes many support files, some in places you just would not expect.

You don't have to worry about some hunks ignored, it is common, and simply depends on the ROM and device. Hunks failing is a different matter, failed hunks usually mean the patched ROM won't work.

But no matter the result of the patching, it is not dangerous to test the resulting pdroid.zip. It only contains system apps, something that is completely overwritten by flashing any ROM. The solution to flashing a bad patched zip is merely flashing the restore.zip or the entire ROM itself.

You probably have a working pdroid.zip already, since you only reported ignored not failed hunks.

Edit c-pim- just saw your last message. Thanks for all the builds that advance the project. My respects to you and your girl.
[LG Optimus 2x] Keithn:
I have it working on my fascinate. The thread is Here. I'm trying to keep it updated with AOKP for now so I that I'd post that over the actual files.
[LG Optimus 2x] mateorod:
I just had another user, this one with a Utopia rom for the vibrant, reach out for help patching and the damn thing fails because of the ServerThread file.

It is almost always the same way, too. One succeeded hunk at the top followed by fails.

I really need to find out what this file does and how it is built. I guarantee that all these custom rom builders are changing not one lick of code. Some may be, but that is an exception to say the least.

With this many patching failures, all the same file, all the same basic pattern?

I am missing something, I just don't know what. I'll dig some more tonight.
[LG Optimus 2x] c-pimp:
The only thing I can think is they are built from a different source from akop but alot have the aokp control settings added, I wonder if that has anything to do with it .... something to look at at least...

with each patch is it the exact same hunk that fails or not I wonder, I'll check when I get home

Found out myself that patching fails pretty much at same point no matter what combo of patches I use on slim rom which fails at all the places that we are having troubles with.... I have got more info on slim but I dont know what im doing enough or looking at with github yet....

from this thread it looks like slim was originally built from aosp crespo files

http://xdaforums.com/showthread.php?t=1390118

this is the info here as well

Source:

https://github.com/krarvind/

Rest:

http://source.android.com

Im trying to figure out alot of things at once but learning about github right now and with the crespo source already built I hope I can figure out how to add his github source to my build and build a patch from that but its proving to be alot to take in quickly for me hehehe
[LG Optimus 2x] Lanchon:
well the danger is that information may leak. and on top of that, i don't have the tools to test that each and every protection in the PDroid patch is working correctly. i don't feel that smali patching is a trustworthy alternative to source level patching if hunks are ignored.

i'm running a maguro skankwich cm9 kang from around the day the first patcher version was released. i tried a couple of nightlies till i found one that didn't cause ignored hunks and im running that rom ever since. after that i installed many untrusted apps and i don't want to risk leaks. I will stay on this rom till i can apply a patch cleanly, or if i can't i'll have to build my own patched source cm9. i'll also try to convince my kanger to integrate PDroid :)

in any case, i think an app that tests every API intercept in the PDroid patches would be a important addition to the framework.
[LG Optimus 2x] mateorod:
Dude, you're missing what I am saying. Those ignored hunks are occurring because your ROM does not have that file.

How is information going to leak through a file or protocol you don't have?

Like I said, fails are a different manner.

Your testing ideas are fine. But that's probably not gonna be the result of this thread.
[LG Optimus 2x] pastime1971:
building is really easy, especially maguro.

i can build one for you, but then it will miss out any feature that your kanger added. besides, i can't just blindly build PDroided ROM for every device, mostly because i can't test them.

most favorably, it would be great if you can convince him to include pdroid in his kang. we have the most popular kang for cm9 p990, which already does that.

as for API, PDroid source has various Log here and there for development, but then it was commented out once it was functional. if you need a test, we can enable those Logs so that you can capture what is going on. i have done it for LocationManager when i was tracing what is going on w/ GMaps.
[LG Optimus 2x] SAI Peregrinus:
I'm that user.

So, looking at the aokp-services.patch file from the smali patcher (since Utopia and the other failing custom roms tend to be a weird mix of AOSP/AOKP/CM9 I figured I'd start with AOKP.)

stock-services/smali/com/android/server/am/ActivityManagerService.smali certainly seems to be patching frameworks_base/services/java/com/android/server/am/ActivityManagerService.java. The base class (not sure if this is the right term, I don't really know Java. Verliog, yes, but that's not useful here.) is also called ActivityManagerService

So I looked more into the patch file, and found that it also patches stock-services/smali/com/android/server/ServerThread.smali (that's the only other file it patches.)

So I checked frameworks_base/services/java/com/android/server and didn't find ServerThread.java. I decided to check AOKP's github too, instead of just ngiordano's (the utopia dev). AOKP doesn't have a ServerThread file.

SystemServer.java's base class IS ServerThread. I think baksmali decomplies each CLASS to its own file, multiple classes that were in the same file may get split up. And the patch certainly seems to be intended to act on the ServerThread class in SystemServer.java. SystemServer HAS been changed between AOKP and this rom,

AOKP imports android.content.IntentFIlter, Utopia does not.

Patch seems to have its first cond_5d1 (the undefined instruction from the logs that failed) shortly after dealing with IntentFilter. Not totally sure, I'm even worse at reading Dalvik bytecode than I am at Java. It may be totally unrelated.

So I think it's a problem with the changes made to SystemServer.java. Hope that helps figure things out.
[LG Optimus 2x] Lanchon:
the ignored hunk error reads "Reversed (or previously applied) patch detected!".

i thought that meant (assuming that PDroid is not applied already!) that the patcher got so lost that it matched the hunk to any other place on the code that already looks like the hunk. i never really looked at dex or java bytecode, but i guess that on many places the java compiler might spit out common sequences of instructions that might be long enough to cause the patcher to spuriously match. (for example in assembly this could maybe happen in prologues and epilogues of functions. in java bytecode i don't know.)

so what you are telling me is that if a hunk patches file X, and file X no longer exists, the patcher will report "Reversed (or previously applied) patch detected!"? i get the idea that the hunk might be expendable since the whole file was deleted, but if that's true i find the reporting very misleading! (even so, i couldn't be sure that what i describe in the previous paragraph isn't happening, or do you think that is too improbable?)

i already set up a VM to build cm9 and ran my own maguro builds, but it gets boring to do repeatedly and my machine is really slooow. and yes, i'd miss out on the extra features. so i'd prefer to apply the smali patch if possible.

i've written to fitsnugly of skankwich (google), but he hasn't replied yet. i sent him a PM on this forum, i hope i didn't break any rules. his maguro skankwich thread here doesn't match "PDroid", but maybe he discussed the patch somewhere else and i was too lazy to look for that well enough.

thank you very much, i don't. however i think it would be a good idea to have a test app that exercises all the requests that are trapped by the PDroid patches to verify that the patches are working. at a minimum, the app would report each value it gets along with an ok sign if the value is as expected for a blocked piece of data. or the app could even change its own privacy settings in the sqlite db and repeatedly query the info to exercise the patches better. anyway, i'm just tossing the idea around in case somebody likes it.
[LG Optimus 2x] robjective:
The mediafire link for the smali patcher for Linux seems to be down. Checked the site with downforeveryoneorjustme, and it looks like the whole site is offline.

I used the ICS patch for CM9 that was in the G-Nex forum. It referenced a specific build date of CM9, but shouldn't the patch be good for any CM9 build?
[LG Optimus 2x] SAI Peregrinus:
CM9 is still under pretty rapid development, so they are changing things. If something that was patched gets changed is can break the patch.
[LG Optimus 2x] mateorod:
The patches themselves did break the once, but new patches send the old are included in the patcher. We use it a lot here, and would now if the patches themselves break.

I'll check the link, and will put up a new link if it is down.
[LG Optimus 2x] pastime1971:
i just checked the latest, pp20120515v043.zip, http://www.mediafire.com/?71wwjs0p1ps2796

it downloads fine for me, but i'm the owner and more importantly i'm in U.S.
[LG Optimus 2x] robjective:
It worked for me now. Must have been a temporary glitch. Thanks.
[LG Optimus 2x] ido:
Hey pastime1971,

Can you please help me patch Samsung galaxy II AT&T i777 based on [XWLPD-4.0.3/4-ICS] SHOstock2 v3.0.3 ROM

This is based on a stock ICS (i9100-XWLPD Unbranded/Netherlands ROM)

You can get the original here:

http://xdaforums.com/showthread.php?t=1563747
[LG Optimus 2x] pastime1971:
is the ROM DEV compiling it from the source ?

our patcher fails. looks like it is quite different from AOSP.
[LG Optimus 2x] ido:
I don't think he's compiling it from source, but thats just a guess.

Pdroid patcher worked great on the 2.3.6 version of samsung's stock ROM.
[LG Optimus 2x] c-pimp:
I can try crespo patch on it later tonight?

Where is it failing?

Are you saying Linux patcher is failing or what doesn't work with that rom?
[LG Optimus 2x] pastime1971:
do you mean GB by 2.3.6 ?

it could be because there has been not much significant changes to frameworks until Gingerbread, but Honeycomb completely changed it to support tablet. and that's why we are having so much trouble... (in my opinion)

as version number implies GB was a minor upgrade, HC was a totally different thing. (right, guys?)
[LG Optimus 2x] pastime1971:
i just wanted to inform you that patcher v0.43 works to patch the latest (2012.05.26.) nightly of CM7 for HTC ace (Desire HD?)

patcher 0.43 : http://www.mediafire.com/?71wwjs0p1ps2796

nightly: update-cm-7-20120526-NIGHTLY-ace-signed.zip

how to : see the post #4 in the first page

patched frameworks: pdroid.zip & restore.zip

whether the patched ROM works or not is to be tested by device-owners.
[LG Optimus 2x] baka2x:
@pastime1971 Thanks a bunch for the AOKP patcher! I used the original patcher by svyat on my Note with GB and it worked well, and my question is when I flash the patch made by your patcher, it gives me a message after rebooting. It'll say:

"Android is upgrading

Optimizing application xx of 80"

Is this normal? I flashed this on a GNex Maguro on AOKP b37.
[LG Optimus 2x] mateorod:
Yeah, that'll happen when you reinstall a system app. It is rebuilding your davlik cache. Totally normal. Looks cool too, like you're really maximizing you machine.
[LG Optimus 2x] baka2x:
@mateorod

I just had to make sure. Syvat's patcher didn't do this so I was curious.
[LG Optimus 2x] mateorod:
Well, it didn't do it for Gingerbread, right?

This is a new "feature", or whatever, of ICS, afaik.
[LG Optimus 2x] JoeSyr:
Just a little update on testing the different patches (Galaxy Nexus Roms, primarily toro):

-AOKP:Still working as of b37

-AOSP:Finally found a GNex rom this will work on, apparently built from AOSP on 5/28. Still untested on phone, but log looks like a success based on what I've learned so far.

-CM9: Seems to be broken with the latest nightlies. Fails on services.jar. Log output:

# VID= 4.0.4
# MID= cm9
# RID= cm9
# DID=
GARBAGE= framework.jar.out/smali/android/app/ActivityThread.smali.orig services.jar.out/smali/com/android/server/am/ActivityManagerService.smali.orig services.jar.out/smali/com/android/server/ServerThread.smali.orig
GARBAGE= framework.jar.out/smali/android/content/CursorLoader.smali.rej framework.jar.out/smali/android/content/IntentFilter.smali.rej framework.jar.out/smali/android/location/Location.smali.rej framework.jar.out/smali/android/net/wifi/WifiConfigStore.smali.rej services.jar.out/smali/com/android/server/ServerThread.smali.rej
services.jar.out\smali\com\android\server\ServerThread.smali[1892,13] Label "goto_1f8" is not defined.
services.jar.out\smali\com\android\server\ServerThread.smali[1925,13] Label "goto_1d0" is not defined.
services.jar.out\smali\com\android\server\ServerThread.smali[1930,4] mismatched tree node: I_STATEMENT_FORMAT22x expecting I_CATCHES
services.jar.out\smali\com\android\server\ServerThread.smali[1939,4] mismatched tree node: I_STATEMENT_FORMAT35c_METHOD expecting <UP>

Another good chunk of free time and I think I might just be on the cusp of addressing these sorts of errors myself. Until then though, hope this helps with development.
[LG Optimus 2x] mateorod:
This is a straight CM9 build? Those patches are working on the four or five devices I use it with. What is the build date of that ROM?

Could you get me a link to the ROM please?
[LG Optimus 2x] JoeSyr:
From here: http://download.cyanogenmod.com/?type=nightly&device=toro

Sort of confusing there as the two latest builds are both 5-29 in their title, but that log is from the build timestamped 2012-05-30 05:30:18, direct link.

Someone had requested and direct linked me to a build that had the same issues, that I'm pretty sure was the other 5/29 build right below that one on the cm page. Not sure when this began as I haven't been patching nightlies, but the last cm build I got working was 5/18.
[LG Optimus 2x] mateorod:
I'll look at this tonight. I know we have had a bunch of changes just pushed the other day here at encore, but I have patched successfully as of 5/30.

I am making a clobbered build now. When it completes, I will make a patched build and create a new patch as well. See if that helps you.

Thanks for getting back to us!

@pastime A guy on the nook forum reported getting a review of our patcher on a radio station in Germany. I just randomly talked to him, I don't know how it happened or what inspired it, but there it is. I was pretty concerned at first he was giving us credit for PDroid itself, but he knew what he meant so it was all good.

Who'd a thunk?
[LG Optimus 2x] c-pimp:
That's awesome, you guys rock!
[LG Optimus 2x] mateorod:
Okay,

I made a new CM9 build set from current source and made patches. I will go and investigate on some roms tonight.

For those interested, here is a paste of the diffs between the new CM9 patches and the current ones in the patcher. There are some differences, obviously, athough I haven't had time to look at it really. I'll put in some time later tonight.

diff services

diff frameworks

@pastime Our problems, between ROM/patch versions seems to be always with the services.jar patch, right? Maybe we can just include the variations on the services.jar patches, to keep the size of the patcher down.

Also, it might make it easier for auto-patching. Upon fail, it could just try the rest of the services.jar patches until it creates a successful compile. Just an idea, nothing more...

I'll put the patches in the box later if I figure that they are helpful.
[LG Optimus 2x] mateorod:
Okay, pastime, the newest CM9 patches are in the Dropbox. They successfully patch the Toro ROM JoeSyr linked to. When ran through our current patcher, it wouldn't recompile so the log only shows the compile problems, not where the patching failed. I don't know how to get around that, but if you do, I think it would be useful.

Edit: And by the above, I meant have the patching output logged even if the compiling fails. Also of interest, I think it would benefit usersto have the patching output go to terminal and the log, although, again, I don,t know exactly how to make that happen. I choose one or the other when I manually patch, what I'd like is both. Anyway...

I decompiled and patched it by hand with both the old and the new patches. The 5-08 patches (the current patches in our patcher) fail in five places in the ServerThread file. The new patches patch fine.

Now the question is this. Since the 5-08 CM9 patches still work for a bunch of ROMS, what should we do? I guess I will try the new CM9 patches (5-31) on some older roms and see how far back they work. If they still cover the last twenty days of things like encore and otter, then maybe we can just swap the 5-31 in for the 5-08 and not have a complete third set for people.

The old framework and core patches still work on the Toro, so if we do want to consider a move to just having obsolete services.jar patches, this would fit that paradigm.

Let me know what you think, but the new patches are in the box, in /PDroid/CM9/5-31 (you'll see I cleaned it up and organized it by OS).