yashsingh1/xdaforums huggingface dataset:
[LG Optimus 2x] mateorod:
We have new patches for CM9 made already. I am going to cross-check them with the patches I will make from pastime's builds tonight.

PDroid will still work if you flash the CM9 zip, although their may be a small leak in functionality that I haven't discovered yet.

The AOKP failures are obviously more significant, and not-unfamiliar. We'll need some new builds before that can be addressed.
[LG Optimus 2x] mateorod:
Hey I am trying to get at these files. Am I stupid or how do I do this?

The link just sent me to a mediafire signup page. I know a bunch of the upload sites are requiring you to sign up to download files so I did so (reluctantly, but this is where the internet is headed, I guess).

Thinderbird warned me that the email with a pin was a scam, but I figured that as probably overzealousness on its part. But now that I am signed up, your link just redirects me to an upload page.

Bottom line, I guess, how do I find the files?
[LG Optimus 2x] pastime1971:
@ mateorod,

sorry about that.

i should have put a share link, not URL from my web browser.

here is the link to the P930 folder, http://www.mediafire.com/?ey6wglw8evara

you will find two zip files there. cm9 and pdroid/cm9

(if that doesn't work, i will post individual file links here)

i will upload P990 once i test it.

also i will see what i can do about AOKP.

edit: my build on P990 is still broken. can't figure out which commit is causing it.
[LG Optimus 2x] mateorod:
Got 'em. Thanks man.

Update Okay I made patches from both encore and p930, mostly just to check and see if little things like encore not having a a phone would matter and just to see what was up generally. It was something I should have done a long time ago, if we're honest, but I am fairly familiar with the source tree and didn't think that the ROM I made the patches from would matter.

It doesn't.

I have attached the diffs of the two patch sets as well as updated patches for CM9. You'll see in the diff set that the only differences between the two patch sets seems to relate to build date. Their are only a few for each jar, and the ones from encore have the 6/14 date (when I made the builds) while the p930 have 6/16.

So anyway, I believe the process has been validated. Here are the new patches to account for the breakage with the WifiConfigStore

And one more thing of interest. In the same vein of pursuing the differences between our patch sets, I have diff our newer patches with the patches from 5/31. For core and services, the only differences are the same ones from our device diffs, date related. For framework the only differences of note are those related to our breakage, on the WifiConfigStore.

So for this addition to the patcher, I think that we could just add the new framework.patch and then either keep the old services and core patches or begin putting in symlinks. I will leave that decision up to you pastime. But these patches are not small, and we are going to begin to have the patcher swell to a pretty big size if we keep adding unneeded files, especially when you consider that we have new AOKP files needed and that we have yet to truly get to the bottom of the ServerThread AOSP issue.

Which I will try and look at some this weekend.
[LG Optimus 2x] pastime1971:
patcher updated with 2012.06.15. patches, http://www.mediafire.com/?2czevba5b044jnj

@ mateorod,

i will spend some time to figure out the best way to organize/simplify patches.

i also need to finish AOKP patches.
[LG Optimus 2x] pastime1971:
PDroid/AOKP vibrantmtd build at http://www.mediafire.com/?vfbo1sajdjbd8
[LG Optimus 2x] mateorod:
Here are the new AOKP patches. It looks like the only file that had failed hunks was our old friend ServerThread, so I think the only replacement patch that is truly needed is the services.patch. Everything else is redundant.

Thanks for the builds pastime!
[LG Optimus 2x] pastime1971:
AOKP patches updated, http://www.mediafire.com/?5dqd1frtkla1pjq
[LG Optimus 2x] mateorod:
I pm'd you about that other thing. I love the new script, man.

I like the new -h look.

What do you think about adding a number to each option, so users don't have to type in each date exactly?

something like...

aokp : latest	(2) 20120613 (3) 20120510 (4) 20120506
aosp : latest	(2) 20120515 (3) 20120507 (4) 20120506
cm7 : latest	(2) 20120514
cm9 : latest	(2) 20120615 (3) 20120601 (4) 20120508 (4) 20120506

where the usage would be...

./pdroid_patcher <ROMNAME> <ROMTYPE> 3

and 1 would be default/latest.

what do you think?
[LG Optimus 2x] pastime1971:
that would be great.

script needs some work to do so.

i will look into it when i get a chance.
[LG Optimus 2x] baka2x:
Using the smali patcher v0.5.0, I tried to patch CM9 20120618 nightly maguro build. Everything looks fine except for one part. When it tries to apply framework.patch, it skips it. You can see the result below. Otherwise, it's fine. Is it supposed to do that on CM9 builds? I don't get this for AOKP builds.
[LG Optimus 2x] scutworker:
Morning,

I've taken a look at all this and want to get it up and running on my HTC Desire running ICS (this ROM: http://xdaforums.com/showthread.php?t=1355660

What exactly do I have to do to compile it? I guess that I can't use the smali patcher as I don't have an AKOP/CM9 ROM, but can I use the script in the first post?

How do I use this? I have a basic knowledge of Ubuntu that might help, but if anybody can point me in the right direction (or better still have a patch that they have already used on this ROM), then that would be fantastic.

Cheers.
[LG Optimus 2x] mateorod:
That isn't skipping the entire framework.jar patch, just one file that isn't needed for your ROM. Pdroid will be fully functional if you flash the Pdroid.zip.

You don't lose anything by trying the smali patcher. That might be what I'd try first.

As to how to compile the patches, the first post says it all. As to how to get the source and manifest for your ROM, that into will have to come from your device forum.

The AOSP patches look like the likely bet for either method. Good luck.
[LG Optimus 2x] SecUpwN:
Patch for Virtuous Shooter

What an awesome project right here! :) Would someone kind please look at my patch request and tell me if he can provide one for my current ROM? I've already talked to pastime about this, but he says that without the full source of Virtuous Shooter it'll be damn hard to compile a working patch. Maybe somebody reading this would take a minute or two in order to try to compile one for me? Thank you so much, folks!

SecUpwN
[LG Optimus 2x] JoeSyr:
Hoping I can ask a question that doesn't amount to "hey please teach me the basics of reading your code", but I'm tinkering with this at the hobbyist/self-teaching level without a background in programming and I have a few questions:

Pretty sure I grasp the basics of what the patcher is doing; what diff accomplishes and what its targets are here. I'm looking at the behavior of when the patcher fails and when it decides to skip a piece, and taking a stab at what I would theoretically need to know to effectively find a problem, understand it, and fix it. Here are my assumptions so far, and I guess I'm basically looking for some feedback if I'm on the right track:

-When I see "hunks ignored" in the log, does this mean that at some point a human identified that an element does not need to be patched nor could it be, and put in an exception so it will be skipped?

-When I see "hunks failed", is it because the patcher is processing everything, but can only successfully process the items its expecting? So if a custom rom introduces novel code the patcher trips over it? In this case, the human contribution is to identify the element and name it correctly for the patcher so it can either process or skip it?

So my current approach is to open the patcher files in notepad++ and by way of googling what I see, try and learn enough syntax to mimic what's already working on the parts that break. Obviously a more complete knowledge of the language would make this easier but for the amount of time I have to commit to this project, I'm happy to just poke around at this slow pace and learn by trial and error.

Edit: Actually maybe I can be more concise by just pointing to a specific example from logs:

Reversed (or previously applied) patch detected! Skipping patch.
6 out of 6 hunks ignored -- saving rejects to file smali/android/server/BluetoothA2dpService.smali.rej

^My assumption is that this item used to generate "hunks failed"; someone determined it doesn't need to be patched for pdroid to run, so they just added an exception to skip it.

13 out of 15 hunks FAILED -- saving rejects to file 'smali/android/app/backup/BackupAgent$BackupServiceBinder.smali.rej'

^My approach here is to go locate the part of the patcher that applies to this element and determine what assumptions it's making that are incorrect about this rom; either change the patcher to reflect changes in the custom rom, or add an exception to skip it(if I knew it wouldn't negatively impact pdroid running).

Accomplishing that is where I begin to try and teach myself to correctly read the syntax of the code in different files, so my question here is does this sound like I'm on the right track with this approach?
[LG Optimus 2x] pastime1971:
@ JoeSyr

yes, basically.

let say you have a patch that looks like

@@ -123,6 +234,8
STATEMENT_1
STATEMENT_2
STATEMENT_3
+STATEMENT_ADD_1
+STATEMENT_ADD_2
STATEMENT_4
STATEMENT_5
STATEMENT_6

patch command will try to find those STATEMENT_1 to STATEMENT_6 at line 123, and add those two lines there.

if patch find those two there already, with -N option, it will ignore it, thinking it was already added.

if somehow it can't match STATEMENT_1 to STATEMENT_6, it can't figure out where to make a change and it complains "FAILED"

now, patch can also match STATEMENT_2 to STATEMENT_5 only, it will still think that is the right place, and it applies the change, but warns you with "Hunk # succeeded at # with fuzz 2"
[LG Optimus 2x] mateorod:
When pastime first debuted his port of PDroid to ICS, he put it out as a build patch. Which can only be applied to the source code before the build. The source code is human written, and the building processes it into computer readable code. The patcher takes the computer readable code and decompiles that back into smali code.

Something that is interesting about this process is that the source code is NOT the same as the decompiled code. The source code contains build instructions, which is different than the code that the ROM uses to operate. So the source code might involve a process in one file which is then disseminated across other files that use the process, while not being specified in a one to one ratio in the original source.

This tripped me up for quite awhile when originally making the patches. I would decompile the apps, and then search or snippets of code that were found in the original build patches. When I couldn't find huge chunks o those original build patches in our smali patches, I would assume that the patches failed (when I was eventually to find out they were fine).

To this day it is often a source of confusion for when a hunk is ignored. An ignored hunk would appear to indicate that either PDroid wouldn't work without it or that the patching of that file isn't necessary for the operation of PDroid, right?

Well, actually, it just means the code is, like pastime noted, already the way it needs to be for the program to work. It is just a matter of how your ROM is built, and I won't pretend to know exactly how that is determined.

This is how something like the WifiConfigStore file, which as far as we can tell, doesn't have anything to do with PDroid's operation, is

a) changed on some roms after a PDroid build

b) already in PDroid condition on others.

that's why that file is sometimes ignored during the smali patching process.

The process of patching that file goes something like this, where it interacts with a process or function with a PDroid necessary file (like ActivityManager or something) and the build patches sometimes have to change how WifiConfigStore deals with the changed ActivityManager. PDroid changed ActivityManager, and this caused WifiConfigStore to have some different code due to the way ROMs are built.

I could explain this better if I knew more about exactly how an Android ROM is put together from source, but I just don't know that.

The benefit of smali patching is that it gives code editing power to users who don't build from source. But realizing that decompiling is not a straight 1:1 reversal to source code will help understand the patching process some.
[LG Optimus 2x] JoeSyr:
Thank you both, this is very helpful and clarifies a lot of the things I am piecing together for myself.

Funny that you use wificonfigstore for the example, I was actually just poking around with that. Here's what I did:

-Ran a non-working rom through the latest aokp, aosp, and cm9 patches. Trimmed down the logs and aligned them all to compare the differences. All of this was just towards a baseline in learning to compare the existing versions of the patcher that I had to each other.

-Wificonfigstore does not appear in the cm9 log. It appears as failed (29/36 hunks) in the other two.

-So I figure, okay, let's see if I can just copy and paste the wificonfigstore section from the cm9 patch into the aosp patch. If a log from this new patch doesn't mention wificonfigstore, I would assume that changes on this scale are kosher.

-The output was that wificonfigstore still failed, but with 36/36 now. I was in the process of looking to see what sort of dependencies I may have violated in my quick copy/paste experiment, but from what I've read here it's really a deeper interconnection of things than I would have first assumed.

Gotta run now and probably won't have internet for the rest of the weekend, but I look forward to tinkering more next week in my free time. Very enlightening stuff just to pull things apart and try to put them back together.
[LG Optimus 2x] mateorod:
I you'd like to see what the patcher is doing when it applies hunks, replace the following into the script at the correct part (you can see where from the first line)

echo "### apply patches ###" >> $LOG
#PATCH='patch -N'
PATCH='patch -Nlu'
echo "### apply core.patch ###"
$PATCH -p1 -d core.jar.out < $RID-core.patch 2>&1 | tee -a $LOG 2>> $LOG #|| printerror "failed patching core.jar !!!"
echo "### apply services.patch ###"
$PATCH -p1 -d services.jar.out < $RID-services.patch 2>&1 | tee -a $LOG 2>> $LOG #|| printerror "failed patching services.jar !!!"
echo "### apply framework.patch ###"
$PATCH -p1 -d framework.jar.out < $RID-framework.patch 2>&1 | tee -a $LOG 2>> $LOG #|| printerror "failed patching framework.jar !!!"
echo "### apply preloaded.patch ###"
$PATCH -p1 < $RID-preloaded.patch 2>&1 | tee -a $LOG 2>> $LOG #|| printerror "failed patching proloaded.jar !!!"

This is how I have it at home for debugging purposes. Notice the tee which send the output to both the terminal and log.
[LG Optimus 2x] SecUpwN:
Can anybody here PLEASE recommend me a fully 3D-featured ICS-ROM for the HTC EVO 3D which will work with the patcher and the latest PDroid? This lack of support is driving me insane!
[LG Optimus 2x] kobik77:
Just patched CM9 maguro. Seems pretty neat so far.

I wish a firewall would be added too to make this a complete solution.

Sent from my Galaxy Nexus
[LG Optimus 2x] pastime1971:
as svyat mentioned it, firewall is kernel's job.

it is most effectively done in kernel level.

however, it would be great if PDroid can adjust iptables rules like DroidWall does.

for now, we have to use both PDroid and DroidWall.

besides, DroidWall can have different rules for wifi and mobile network.
[LG Optimus 2x] kobik77:
Yeah, I know.

Just merging both pdroid and droidwall into one security solution would be great, instead of having multiple services running.

Sent from my Galaxy Nexus
[LG Optimus 2x] sabret00the:
Is this just the framework or does it also update the UI to take on Android Design Guidelines?
[LG Optimus 2x] SecUpwN:
Pssh, quiet! Svyat is following this thread! I'm sure he'll surprise us soon... ;-)
[LG Optimus 2x] pastime1971:
just framework.
[LG Optimus 2x] alroger:
Don't worry, DroidWall is not a service, just plays with kernel iptables which pdroid could also do.

SGT-P1000N CM9 Tapatalk2
[LG Optimus 2x] jago25_98:
Would love to see 333 ICS ROM for i9000:

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

http://d-h.st/PpL
[LG Optimus 2x] SecUpwN:
PDroid on HTC EVO 3D

Does somebody know a custom ICS-ROM for HTC EVO 3D that is patchable by Auto-Patcher?
[LG Optimus 2x] pastime1971:
You can invite the dev to this thread and encourage him to include pdroid.

It would be a.piece of cake for him to add the source patch from the post #1 here.
[LG Optimus 2x] daoth:
<snip>
[LG Optimus 2x] pastime1971:
JB port of PDroid

i am working on an initial porting of PDroid onto Jellybean, and it looks promising.

I just need to iron out one or two kinks.

Will do over the weekend.
[LG Optimus 2x] kobik77:
Good news pastime!

Would love to test a version of auto-patcher for JB.

I really miss PDroid.
[LG Optimus 2x] pastime1971:
which rom and device are you running ?
[LG Optimus 2x] kobik77:
Galaxy Nexus running Jelly Belly which is now based on AOSP

http://xdaforums.com/showthread.php?t=1738197
[LG Optimus 2x] robjective:
+1

Getting ready to install Bugless Beast on Toro. Be happy to help with test flashing.
[LG Optimus 2x] pastime1971:
while compiling JB with PDroid, something unexpected happens:

trouble writing output: Too many methods: 65603; max is 65536. By package:

any java help ?

edit: after google search, it sounds like it is an intrinsic problem. cannot be easily fixed. i guess that is why some ROMs have framework2.jar in addition to framework.jar. now the question is can we devide framework into two jars like those ? and how ? this could be a problem to anyone who is trying to expand JB framework. i was told that JB AOSP framework already has 65427 methods, which is very close to 65536.
[LG Optimus 2x] mateorod:
I've seen this already. It may be a JB bug. JBQ on the android boards has talked about it, and there is a temp solution, although I don't know it off hand.

I'll see if I can find a link. Does it complain about too many constants?
[LG Optimus 2x] pastime1971:
as far as i can tell, just method. pdroid adds about 273 methods.
[LG Optimus 2x] mateorod:
Found where I saw it...this might help...

http://groups.google.com/group/android-platform/browse_thread/thread/b11e88da5742c705#

patch..

https://github.com/CyanogenMod/andr...mmit/854f6f736b90d33b59b5a85bcecf72a416c43b7d

Edit: I hadn't seen your edit...this is CM's solution for framework.jar method max's. So I think you can use it for this.

I had wondered about framework2.jars, but had never connected it to method max's before.

Yeah, the reason I remember this was marvelling that they only left 200 method wiggle room. OEMs always seem to pack the code will all sorts of crud, I bet that Google will have to solve this for Sense and TouchWiz starting yesterday. Those ROMs are over 250 mb for ICS.
[LG Optimus 2x] pastime1971:
yeap. that's probably what we need to do.

however, i don't think we can ever support AOSP JB, which probably doesn't have it.

we can supply AOSP ROM directly. but not in auto patcher.

CM9 (and probably AOKP) should be fine.
[LG Optimus 2x] mateorod:
Oh, I don't know. I bet they either implement a dex change or decide to mimic the CM solution soon, maybe by next update. They are going to need the room for their own updating purposes as well as provide the space for OEMs.

We could always think about removing some methods. :p There are some functions I would be happy to sacrifice in order to have PDroid on grouper...
[LG Optimus 2x] karamelos:
Work fine on this rom

Paranoidandroid v1.5 (gnote)

http://xdaforums.com/showthread.php?p=26306176

Patch post

http://xdaforums.com/showthread.php?p=28791858
[LG Optimus 2x] tonyp:
Oh it's working for you? I tried it before but it didn't.

Did you run the auto_patcher with default values?

It's strange, we should have the same framework base - or is the Note port based on v1.6 of PA?

That version doesn't work for me because the 2x has another chipset and they moved to native code.
[LG Optimus 2x] karamelos:
Hi,

I running on the latest update (first link) i make one (&more) with a source but i've got great bootloop (windows & mac) but autopatcher v0.7.5 work fine (ubuntu 12.04 64 bits jdk7)

Try it :p
[LG Optimus 2x] tonyp:
Already tried with 0.7.5, doesn't work for me on v1.5. Thank you anyways.
[LG Optimus 2x] roalex:
Hei, nice work with the patches...one question could you upload the JB patches too ? i know there are made for the reverse engineering, but for AOSP building at least on Jelly ?
[LG Optimus 2x] pastime1971:
PDroid adds ~300 more methods to framework.jar and on JB, java crapps out because it exceeds 65536 method limit.

a workaround would be splitting framework.jar into two jar files, but it already has some issues that i haven't been able to resolve yet.

i will upload it when i resolve this issue, and possibly get some confirmation that it works.
[LG Optimus 2x] roalex:
Oh, had no idea, thanks for the reply !
[LG Optimus 2x] pastime1971:
PDroid port to AOSP4.1.1 JB

i finally managed to compile AOSP 4.1.1 with PDroid

maguro http://www.mediafire.com/?7385myvyu03bfhb

i needed to make some changes in PDroid source part. since i haven't been able to compile CM10 for P990 yet, this is untested.

if you have maguro, please nandroid backup, flash it, and test if it works.

i had to split framework.jar into 2 jar files, because of 65535 method limit issue. (CM10 does so.)

(this is tricky for auto patcher to deal with 2 jar files now.)
[LG Optimus 2x] Amoh77:
4.1

Installation aborted :(
[LG Optimus 2x] mateorod:
I have the source for AOSP patched and ready to build. I haven't been able to see if it will compile yet. I am in the middle of upgrading my box to 64 bit. The process has involved making another Linux box for 32 bit, and setting up a samba server in order to get all my work over.

I can hopefully see how the build goes soon. I am trying to keep an eye on android-platform, I have gotten the impression from JBQ that Google is going to introduce a solution for the method cap at some point.
[LG Optimus 2x] pastime1971:
hmmm.

does anybody know how to make an AOSP rom ? i did "make otapackage"
[LG Optimus 2x] pastime1971:
cool. that would be useful...
[LG Optimus 2x] kobik77:
Can you elaborate a little more on what are the difficulties you're having?

Would some scripting magic will be enough? Or is it something more than that?
[LG Optimus 2x] pastime1971:
i had to wait for a build to complete, so i restored my CM7.2 nandroid backup, and tested PDroid/CM7.2/Google map. and i got the same result.

gmap still finds me through wifi.

it makes me think that it does something like "traceroute" and send it back to google and build a location database.
[LG Optimus 2x] temasek:
You are right.

Initially it doesn't finds me thru wifi but I kept trying again and again and finally it shows my location. :(

Cm7.2
[LG Optimus 2x] wkwkwk:
Hi.

It seems that the 1.32 patch is causing a lot of app crashes and even system_ui crashes.

I've reverted back to the 1.27 one and no app crashed so far.

Anyone else experienced this?
[LG Optimus 2x] pastime1971:
really ? which apps crash ?

i didn't notice it. but then, i don't have many apps on my phone.

there have been a significant amount of changes from 1.27 to 1.32. i guess it is possible.

edit: when you have a chance, could you grab logcat of app crashing ? it would be also helpful if you uncomment Log in frameworks/base/privacy/... to increase debug info.
[LG Optimus 2x] wkwkwk:
Darn, didn't think to take a logcat and I already changed to the firmware with 1.27 patch.

I found it strange that system apps were crashing and a few user apps as well. The UI was also randomly restarting.

After patching with 1.27 seems stable now. Maybe it's a problem isolated to i9100, who knows.

Maybe I'll test again and I'll take a logcat then.

Cheers.