yashsingh1/xdaforums huggingface dataset:
[HTC One X] Phil3759:
Strange, either the board reports a negative x and y coordinates or the first log was bad as max y is really off

I will release a new version with the last log

For screenshots, no need to an external tool. You just slide left outside a menu and it takes a screen shot

Also, I need to know if the bottom virtual buttons work or are also offset (well, they are vertically offset, but should be horizontally aligned, that is when you touch at a specified button level, it should work

Well, in v5 (no ETA, but not for the next weeks), the calibration will be automatic in code
[HTC One X] Patrics83:
I must say that the calibration method is really hard on the OneX. Since the touch area goes outside the graphical screen.

However, horizontal alignment is good and should be 100% accurate compared to the vertical bottom values. hopefully i managed to lift my finger just in time :thumbup:

I know about the built-in screenshot method, it works and all that but I had those screenshots on my pc.

Sent from my HTC One X
[HTC One X] Phil3759:
Ok, i see now. You have the second bottom area that doesn't account as main display but is reported as a continuity in coordinates (same board)

Yes, vertical will be fixed then, but, like with one xl, bottom virtual buttons will end up over bottom area i fear (hard buttons)

Are the bottom virtual buttons useful for the one x? In Gui settings they can be disabled, but i can also push them above
[HTC One X] Patrics83:
Ah I see... Hmm this is kinda tricky then.

Also it explains why the software buttons responded when I pressed slightly under them (on hardware buttons)

Sent from my HTC One X
[HTC One X] Phil3759:
New v4.94.3

Hope this will fix the touch precision. For the One XL I am done it seems for precision, so it is a matter of time and testers contribution here too hopefully

Download in same place, here: http://www.mediafire.com/?w59ydbwgoarvd

Let me know how the virtual bottom buttons end up and if the bottom logs overwrite the hardware buttons too

You can also disable bottom virtual buttons in GUI settings

Did not mean to hurt you. Was late and I went into many thoughts about the issue
[HTC One X] sirioo:
https://dl-web.dropbox.com/get/philz_recovery.log?w=AAB1L_5xEdLBGdZXREdtq4Kh25P5xzN5UVZ9zmmLcmY0oA

touch no works :(
[HTC One X] min-dfreak:
For me its working great, but i need to doubleclick on the menu items. Is that normal?
[HTC One X] Phil3759:
You probably have a newer board

Read post 2, get debug version and post log. Or wait v5, in a few weeks / months
[HTC One X] Phil3759:
There is an option in gui settings that you maybe altered
[HTC One X] VertigoOneX:
Is there a way to have touch and usb mount? I flashed recovery.img and then also the zip but Ive only got either touch or usb mount working with recoveries..
[HTC One X] Mr Hofs:
Philz supports touch. Also ums. Connect and wait until it pops up, may take minutes.

Only flash the recovery.img. installing the zip won't do anything !
[HTC One X] Phil3759:
In the aim of updating this, I need to know if last stock CWM builds for your device are fine

Do I still need a prebuilt kernel?

Any issues with my current recovery?

Drop this: I just saw the prebuilt kernel in official cwm is still 1 year old, so you'll have same touch issues if I revert

Will update to 6
[HTC One X] lukes91:
your current recovery is great! i never faced any issue...
[HTC One X] myheroduane:
Agreed.
[HTC One X] Patrics83:
The recovery works great, no issues at all!

However, if it's possible I would like to see that adb is loaded at boot of recovery.

1 min delay is a loooong time to wait when testing stuff ;)

Sent from my HTC One X
[HTC One X] Thunder07:
Since you're working on this,

can I just remind you of my earlier proposal to support KL kernel flashing process, thanks

Send From My HTC One X
[HTC One X] Phil3759:
using vold this should be no problem anymore

Could be first versions need a little debugging though, we'll see

Sorry, I am a little in a burning stage...

What you can do is take time to post all what I need in one single post, trying to explain exactly what you want to achieve and resources/script recovery should run when installing the zip

That way, I bookmark it, add to my todo list and promis to give a definitive answer

Hope you understand what I mean, as a dev yourself

Being alone on such a project and updating +60 devices is a real crazy thing
[HTC One X] Daekin:
yes, it is working flawlessly. your recovery is the only wone with all features working (I mean: UMS, touch, ABD) on newest firmware
[HTC One X] forster:
Philz i saw on your devhost that there is v6.01.0. but there is no info on this version whatsoever. I used to flash just .img file to get your recovery working. now when i downloaded this one, it came as zip.

When i uziped it i saw that there is img, alright, but it says date modified 29.02.2008.

So it is clear that i cannot install img as is.

Im on hboot 1.72 s-on, and how should i install this version?
[HTC One X] DeeZZ_NuuZZ:
just flash the latest like you would flash a boot.img extract the recovery.img from the zip you downloaded , put it in fastboot folder and flash it with fastboot flash recovery recovery.img....the same steps as nearly always and for everything we flash in fastboot :P
[HTC One X] forster:
Ok, i got an idea but should i also flash zip?
[HTC One X] DeeZZ_NuuZZ:
NO you have just to extract he .img out of it and flash through fastboot :D
[HTC One X] forster:
Thanks mate, that zip thing confused me....
[HTC One X] shiranmotha:
I have a S-Off HOX. On every thread it says to flash the boot.img over fastboot while flashing a new Rom. Being s-off do I still have to do that...?
[HTC One X] DeeZZ_NuuZZ:
If the Rom supports flashing kernel while flashing Rom then no but if the script from Rom installation doesn't support it you have to flash in fastboot

Gesendet von meinem HTC One X mit Tapatalk
[HTC One X] lukes91:
[MENTION=4666971]Phil3759[/MENTION] thank you for the last update :)
[HTC One X] Mr Hofs:
Hmm i had some trouble connecting as mass storage inside recovery (latest version) went back to 5.15 and all was well again. Could be a point of attention ?
[HTC One X] Forsaked:
Thanks PhilZ for the new Version!

Now "mount USB Storage" get instantly recognized by my Windows 8.1, the 5.x-Version has taken alot of time (up to 2 Minutes) to get recognized. :good:
[HTC One X] Mr Hofs:
Hmm weird i have my non connecting issue then :(

Ah well 5.15 works great !!!
[HTC One X] Phil3759:
try to update phone drivers on PC since it is based on a new kernel
[HTC One X] Mr Hofs:
Ah oke, will check that out asap. Thanks Phil !

Keep up the great work
[HTC One X] Thant:
Are the new version support this think [Kexec] Kernel Lighter from Tunder or he not send the information?
[HTC One X] Thunder07:
My exams start on Monday,

So I haven't had the chance to do it,

I'd like to make it detailed as to explain how and why!

However,

I did post one few pages back if that's any help.

Send From My HTC One X
[HTC One X] Thant:
Thanks in advance:good:
[HTC One X] Phil3759:
Yes, really

I will be watching this thread for any update / guide from you to implement things
[HTC One X] szunyi77:
Thanks for the latest update philz_touch_6.01.0! :good:

I have a question:

The previous nandroid backup, and also made ​​the original system version 5.15.9.

Version 6.01.0 able to restore with no problems?

To revert to the stock system, it will be back to version 5.15.9 recovery do?

I hope you understand

Thank you for this beautiful and powerful recovery!

Very nice work!
[HTC One X] Mr Hofs:
The nand made with 5.15 should be compatible with 6. And no when you restore that nandroid backup the recovery will not return to 5.15 unless you manually flash the recovery.img from the nandroid backup folder.
[HTC One X] szunyi77:
Okay!

thank you very much for the information!
[HTC One X] Thunder07:
http://xdaforums.com/showpost.php?p=46161334&postcount=371

i posted this a while if it's any help, otherwise ill rewrite it after the exams.

Edit:

I've updated that post, hopefully it's more helpful now.
[HTC One X] szunyi77:
I wanted to exchange custom wallpaper, but it does not replace ... (

We made a screenshot png, and I copied the folder custom_res.

What resolution jpeg must make it work?
[HTC One X] Phil3759:
read the FAQ

you need png

and ideally same res as your device screen
[HTC One X] Phil3759:
Just for me to understand

when you flash a zip, recovery should check if we are extracting boot.img before really writing it to the device boot partition

if it finds instructions to flash boot.img, instead of flashing it, it should unpack it to your kernel folder

after unpack, it should offer user to reboot into main system

your custom kernel will use zImage and ramdisk to what ever I do not know why

Well, the question for me is in point 4

Why should I go into the steps 1 to 3?

What is the practical use of this?

Sorry, but I never owned a HTC device to even figure out why all this would be needed
[HTC One X] Thunder07:
yes,yes.

just do 1 and 2...

no need to offer a reboot, if the user wants to reboot, they can do it themselves...

you see the HTC One X doesn't have s-off and thus we're unable to flash kernels using recovery or any other means beside a PC...

so i've come up with a way to load a Live kernel (from my chosen location) during boot... and that requires it to be unpacked.

a user has to flash my kernel once through a PC..

then using an android app through android they can choose what kernel to boot, it basically does what i want you to do through the recovery..

but the app does come with 1 limitation... if you start with a fresh install (full wipe), you'd format /system /data,

thus they wont be able to boot into android as they lack a live kernel (which is located in /system or /data) to boot into.

also with your help not only will this not be a problem...

we'd also be able to technically flash kernels through the recovery...

as my kernel will detect the newly flashed kernel and boot it.
[HTC One X] Phil3759:
I better understand

Basically, this would be valid only for HTC One X AND your custom kernel, not for many other devices...

It is not a big deal probably. sk8er modded once cwm to circumvant assert lines in zip, I can see if I can use his code

Now, won't it be possible that you just modify your kernel in one of these 2 ways to fix your kernel limitation:

if your kernel doesn't find a ramdisk extracted (after it was wiped), it uses another one really flashed in boot.img, that is your modified kernel. Or maybe space is limiting you in boot.img partition? In that case, did you try lzma?

users could setup your kernel config to look in sdcard. That way, when they wipe, they do not loose ramdisk/zImage that are setup in your kernel, since sdcard is rarely wiped?
[HTC One X] Thunder07:
yes that's true, that's why i asked for an option to keep it disabled.

i've considered many options including those...

for one it's not practical, as I'll need few different kernels for Sense vs ASOP, then ill need an accompanying ramdisk... and just as well, ill need to find a way to tell if the rom is Sense or ASOP before i can do anything...

thats not even where the problem starts... as do kernels, one thats made for Ice cream, wont work for JB which wont work of Kitkat... and future updates... it's just not reasonable.... & that's not the main reason i ask,

i ask because flashing kernel through recovery is how it should be done... as per S-off'ed devices.
[HTC One X] Phil3759:
One big limitation of the unpackbootimg arm binary though is the ram disk offset

It doesn't account for it

That's a serious issue as stock kernels can have a different offset from aosp/aokp

Offset can also varry between different stock versions
[HTC One X] Thunder07:
just to make sure.. with the offset..

you're referring to the signature at the very beginning of stock kernels that must be removed before we are able to unpack them?

true and i totally forgot about them...

but... who would be installing stock STOCK kernel using custom recovery with an option for KL Kernels??

in that case anyway you'd receive stderr msg and just report it back to the user.

also from my own custom rom use.. i know that any stock/sense rom would come with insecure boot img...

thus it's no longer fully stock and would work normally.

finally,

abootimg binary might be a good replacement...

it's also very handy since it gives you the option of extracting zimage/ramdisk separately

although i wouldn't worry too much about stock kernel.
[HTC One X] Phil3759:
I meant the ramdisk offset to fit data in boot.img

I tested some time agao the unpackbootimg for some ideas in recovery. I had to drop it because most kernels use a custom offset:

BOARD_MKBOOTIMG_ARGS := --ramdisk_offset 0x02000000

Without it, they won't boot
[HTC One X] Thunder07:
I don't know for other devices but for the HTC One X, it's always the same[same or not, they always worked][both based on unpackbootimg]..

[TOOL]One X One Click v2.3A|Kernel&Modules|Recovery|RUU|MultiRepack|Root ing|AIO|

[5 Aug 2012][TOOL][CWM] zImage Injector v1.1 [MULTI-REPACK][AROMA] - FIXED

these 2 tools one by me and one by Daekin are as old as the HTC One X...

and has been used countless times with no problem of such sort.

so it wont be a problem.
[HTC One X] Phil3759:
Ok, it's just a matter of motivation. The biggest issue for me is that it is really limited to one device and one specific kernel. The mod is completely non portable for other locked devices. The HTC One for example needs specific ramdisk offset, most Samsung phones and LG phones too...

Al last thing. When I unpack the kernel, where ever it is unpacked, the rom script could still wipe /data and /system killing it

So, we'll have to wait for the install procedure to finish before unpacking the boot.img

This makes things more complex as they need to be split on to different recovery parts, the edify and install zip, which are distinct, but in theory not impossible

I do not promise anything, I will add to my todo list though

At worst, when you have time, you can send me a PM and I will take time to show you exact parts to modify in cwm sources to achieve this and even eventually review your code
[HTC One X] Thunder07:
I get that and I respect that and would appreciate it if you could..

And I'm sure every HOX user would as well.

Generally speaking, attempts at installing a kernel is done at the very end of a script... After formatting any partition.

So it won't be a problem....

Thinking about this now..

Ummmm....

Just throwing ideas around..

What if we compiled an update binary which you'd call after installing a zip file...

That binary would only hook into the methods we want...

We'd still need small update to the recovery and to make it work without any change to any existing kernel zip files.

But it should be easier no?

Send From My HTC One X
[HTC One X] Phil3759:
Oh, in that case, I could add it easily. It could be either a small static binary you write in C or even a shell script able to run in busybox environment. In that case, I only have to include the shell script and unmkbootimg binary in /sbin and instruct to run script at end of install if user configure it.

The binary or shell script must accept arguments with source and target info

$1 will be the zip path, script can call unzip shell command to extract boot.img/recovery.img if they exist, unpack them to $2 and exit

Recovery changes will be very limited. Post-flash script would be invoked after each zip install. The script must list zip contents to check for boot.img/recovery.img

unzip shell command should have all need options. Else, my official recovery builds have a precompiled full zip binary
[HTC One X] Thunder07:
im hoping it will be done without the zip mess.. as this might be limited when the zip contains multiple boot.img.

but let say we do use unzip... how do you suggest we locate boot.img .. as specified by update-script...

as the zip might have multiple boot.img but the script only flashes one.

i've been looking at recovery code and this is what i've found...

android_bootable_recovery / updater / install.c

my question is... is this built as part of the recovery or as update-binary??

(edit: "Build a statically-linked binary to include in OTA packages")

either way its a simple enough mod...

just an example (if i made a syntax error ignore that.. but you get the concept atleast.. hopefully?)

Value* PackageExtractFileFn(const char* name, State* state,
int argc, Expr* argv[]) {
if (argc != 1 && argc != 2) {
return ErrorAbort(state, "%s() expects 1 or 2 args, got %d",
name, argc);
}
bool success = false;
if (argc == 2) {
// The two-argument version extracts to a file.

char* zip_path;
char* dest_path;
if (ReadArgs(state, argv, 2, &zip_path, &dest_path) < 0) return NULL;

ZipArchive* za = ((UpdaterInfo*)(state->cookie))->package_zip;
const ZipEntry* entry = mzFindZipEntry(za, zip_path);
if (entry == NULL) {
fprintf(stderr, "%s: no %s in package\n", name, zip_path);
goto done2;
}

[B][COLOR="Blue"]	if ((dest_path == "/dev/block/platform/sdhci-tegra.3/by-name/LNX" || dest_path == "/dev/block/mmcblk0p4"))
{
if (strstr(name, ".img") != NULL) {
dest_path2 = "/tmp/" + zip_path;
FILE* f = fopen(dest_path2, "wb");
if (f == NULL) {
fprintf(stderr, "%s: can't open %s for write: %s\n", name, dest_path, strerror(errno));
goto done2;
}
success = mzExtractZipEntryToFile(za, entry, fileno(f));
fclose(f);
system("/sbin/mybatch /tmp/" + zip_path + " " + DestinationAsPerSetting);
}
}[/COLOR][/B]
FILE* f = fopen(dest_path, "wb");
if (f == NULL) {
fprintf(stderr, "%s: can't open %s for write: %s\n",
name, dest_path, strerror(errno));
goto done2;
}
success = mzExtractZipEntryToFile(za, entry, fileno(f));
fclose(f);

done2:
free(zip_path);
free(dest_path);
return StringValue(strdup(success ? "t" : ""));
} else {
// The one-argument version returns the contents of the file
// as the result.

char* zip_path;
Value* v = malloc(sizeof(Value));
v->type = VAL_BLOB;
v->size = -1;
v->data = NULL;

if (ReadArgs(state, argv, 1, &zip_path) < 0) return NULL;

ZipArchive* za = ((UpdaterInfo*)(state->cookie))->package_zip;
const ZipEntry* entry = mzFindZipEntry(za, zip_path);
if (entry == NULL) {
fprintf(stderr, "%s: no %s in package\n", name, zip_path);
goto done1;
}

v->size = mzGetZipEntryUncompLen(entry);
v->data = malloc(v->size);
if (v->data == NULL) {
fprintf(stderr, "%s: failed to allocate %ld bytes for %s\n",
name, (long)v->size, zip_path);
goto done1;
}

success = mzExtractZipEntryToBuffer(za, entry,
(unsigned char *)v->data);

done1:
free(zip_path);
if (!success) {
free(v->data);
v->data = NULL;
v->size = -1;
}
return v;
}
}
[HTC One X] Phil3759:
No, that's updater binary for device

https://github.com/CyanogenMod/android_bootable_recovery/blob/cm-10.2/extendedcommands.c#L145

which directs here:

https://github.com/CyanogenMod/android_bootable_recovery/blob/cm-10.2/install.c#L344

Which executes update-binary from zip:

https://github.com/CyanogenMod/android_bootable_recovery/blob/cm-10.2/install.c#L194

Basically, the update-binary that comes with the zip will directly process all commands in updater-script

So, if you need to manage a zip with multiple boot.img files, you'll have a big job.

1- parse updater-script to try to figure which boot.img is flashed

2- account for eventually aroma installers

3- account for more and more installers using a faked update-binary which is replaced by a shell script

4- edify scripting can also be used to flash boot.img files, but only by calling install_zip() function

Basically, a worthless task for me personally. Either you stick with single boot.img files, or you have a huge work to do

Do not forget some can rename their boot.img files in the zip

A simpler way would be: modify the updater code and compile your own. On install_zip(), you have to replace /tmp/update_binary by your modified one

Your modified update-binary would copy the flashed boot.img to a safe tmp location

On exit, you unpack your copied boot.img

However, even that way would fail if zip uses the faked update-binary which is a shell script

So, in any case, it is a non doable thing in a simpler way
[HTC One X] Thunder07:
i know that will be alot.. that's why im changing my mind all the time... until i though of a 2nd script after installing a zip...

and that 2nd script would be calling a modified update-binary...

everything in it will be stripped par a modified package_extract_file & write_raw_image.

so to recap..

we'll be compiling a modified update binary... which would be located in the recovery (/sbin)

when a user install a zip (normally) and that's done, the modified binary would be called,

this binary should take care of the rest, extract the boot.img and unpack it.

so recovery modification would be limited to (A) adding the settings (B) adding a line to call the modified binary.

P.S. as i said earlier i have exams coming up... and i know myself...

ill forget about study and focus on this...

so lets leave it at this and ill get back to you after the exams,

hopefully we can work something out.
[HTC One X] Phil3759:
The modified update-binary must be copied to /tmp/update-binary after zip extraction, to overwrite the one from zip

It must at some point copy the boot.img to be flashed

The method has a huge limitation: all new installers using a shell script in place of true update-binary will be broken

Take your time, good exams

I am very busy right now any way
[HTC One X] Thunder07:
small price to pay...

and i've done this kind of thing (with update-binary).. there is no need for it to be in tmp...

you can run it from anywhere and point it to the zip file and it will run.

(the only reason the recovery copys it to the /tmp.... is because it can't run it from the zip file directly)

./update-binary 3 stdout /sdcard/kernel.zip

about the limitation, the way i'm thinking about this...

for one, a normal installer will run, followed by the modded one...

thus whatever breaks in the modded one would have already been applied in the normal run (hopefully, without actually breaking the entire thing :p ).

Good Night.
[HTC One X] Phil3759:
You cannot do that, else you will be installing things twice

Normal installer once finished, will clean up temp files as instructed in updater-script

So, in that case, you'll have to extract zip again and reflash it with your modded updater-binary

All popular root scripts (SuperSU, Koush...) use shell scripts instead of the update-buinary. So, you cannot break them.

Your mod should keep this compatibility

Extracting zip files twice is no way, mainly for big installers. Things will be slowed down a lot

1- you must check if update-binary is a shell script by looking for its magic number (exec files)

2- if you detect a binary, you must start a modded update-binary instead of the one in zip

In my sources, I use magic number to check for gzip/png files

You can use a same approach

That's the only proper way to go
[HTC One X] Thunder07:
the reason im installing everything twice.. is to avoid breaking anything....

but don't worry i wont be installing anything twice anyway...

the modified updater-binary would only extract the boot.img (and by boot img, i mean whatever is listed in the update-script)...

it will ignore every other instruction, thus it wont install anything twice...

that way.. it wont break anything not even aroma... as the 1st run would be normal.

also if you look through the code...

at any one time.. the zip is never extracted, until instructed by the update-binary...

and only the part requested will be extracted.. thus the 2nd run will focus on *.img

mzExtractZipEntryToFile(za, entry, fileno(f));

I hope we understand each other now?

now, which one would you prefer?

1) adding a special zip installer option that would prompt the user every time before zip selection

2) adding a setting which would apply to normal zip install
[HTC One X] mhoss48:
How to replace twrp with it ? Touch ain't working on twrp
[HTC One X] Mr Hofs:
I sent you a link and the info that you have to flash it via fastboot lastnight already