I appreciate the time you are taking to read this. I searched a lot, but could not find an answer to my problem.
I am trying to implement a recent patch to bidi text rendering that was created for CM rom and runs on Nexus 1. I downloaded the vanilla source code to 2.1, and compiled it with and without the patch. Then I disassembled framework.jar and compared the smali files, to discover that the following ones were modified:
android/graphics/Canvas.smali
android/graphics/Canvas$EdgeType.smali
android/graphics/Canvas$VertexMode.smali
android/text/Layout.smali
android/text/SpannableStringBuilder.smali
android/text/Styled.smali
android/widget/TextView$CharWrapper.smali
My idea was that if I run baksmali on the framework.jar file from my Desire, replace these files with the new ones, run smali on the result, repack it as framework.jar and upload it to the device - the fix will be implemented.
This actually worked very well for a previous fix, which involved only the file StaticLayout.smali. It worked without having to sign framework.jar; however, that fix did not change the file size, whereas the current one does change it - especially for Canvas.smali. I did not try to sign framework.jar - I don't really know how to and if it is necessary.
The result was a bootloop. Logcat showed that the device is unable to load a native library:
Code:
D/AndroidRuntime( 103): --- registering native functions ---
W/dalvikvm( 103): Unable to register: not native: Landroid/graphics/Canvas;.drawText (Ljava/lang/String;FFLandroid/graphics/Paint;)V
E/JNIHelp ( 103): RegisterNatives failed for 'android/graphics/Canvas'
E/AndroidRuntime( 103): Unable to register all android natives
This is where I am stuck. What I really wanted to do was to create a script-based fix that would work on any device running 2.1. It was possible for the StaticLayout fix. Now I'll settle for figuring out how to make it work for the Desire.
I am attaching Canvas.smali, the file I think is responsible for the problem, in 2 forms: vanilla is compiled from source with no modification, patched is compiled from source after the patch. It seems that the other Canvas files were unchanged by the modification.
Thank you very much in advance!
I am a fool - you would need, of course, the smali file that actually works on the device. Attached here.
ClassicalDude said:
I am a fool - you would need, of course, the smali file that actually works on the device. Attached here.
Click to expand...
Click to collapse
this is a bit off topic but how to change in .jar file? thanks
jullejul said:
this is a bit off topic but how to change in .jar file? thanks
Click to expand...
Click to collapse
http://www.villainrom.co.uk/viewtopic.php?f=61&t=921&start=0
this will teach you how to patch a jar file..
hi thanxxxx
NEWS :
Koush's bmlunlock (a simple IOCTL send to the bml device) is just out and can replace redbend_ua !
http://github.com/CyanogenMod/android_device_samsung_bmlunlock
Hey
Is Flashing from update.zip the new trend ?
'Don't know but here is how you can do it quite easily using this template.
If you target a GT-I9000 on Eclair, you'll need to customize one thing :
In build-update-zip.sh, set DROID_HOME to the source code path for your local Android repository.
If you target another Galaxy S phone or another version of Android, you'll need to adjust ro.hardware and ro.build.id properties accordingly.
This template is done for Linux/Unixes/OSX.
If Linux cost too much for you or your employer, please contribute by sending a .bat equivalent to the .sh
Of course, you also need to put a valid zImage to replace the template's empty zImage
Feel free to adjust to your needs. License is WTFPL
Note : requirement are Java and Android source repo, already build.
Looks awesome!
I have a question though... why do you need to flash the kernel in an update.zip at boot?
As far as I know, the system will read the kernel at boot up time and load it into ram. It won't access the on-disk file again until the next boot. If that is true, then flashing while running should be 100% safe, right?
RyanZA it's an update.zip, not a ramdisk.
The point is getting an easy flashing method, requiring no computer.
And you don't even need to root your phone !
curio, as i see this script is quite simple, so dont u think this all could actually be done on the phone directly? i mean if people cant afford a linux machine...
edit:
sorry for major dumbness, but do you think this could also somehow be used to reflash a nandroid backup?
FadeFx said:
curio, as i see this script is quite simple, so dont u think this all could actually be done on the phone directly? i mean if people cant afford a linux machine...
Click to expand...
Click to collapse
I don't think the signing tool works on android -- maybe it does? Anyway editing scripts on a phone seems a bit silly!
FadeFx said:
curio, as i see this script is quite simple, so dont u think this all could actually be done on the phone directly? i mean if people cant afford a linux machine...
edit:
sorry for major dumbness, but do you think this could also somehow be used to reflash a nandroid backup?
Click to expand...
Click to collapse
Nope actually this is not dumb at all
Yes the flashing part run in updater-script can be started manually.
In the script :
Code:
"redbend_ua", "restore", "zImage", "/dev/block/bml7"
The update.zip presented here mainly targets custom kernel creators in order to give them another way to distribute their work.
This is a working example of how to use redbend_ua programmatically, hopefully it may help new ideas coming. redbend_ua usage is not limited at all to kernel flashing.
PS : you can use this template with windows as well, you'll just need to translate the ulta-basic .sh to a .bat script, or do the signing part manually.
supercurio said:
Hey
If you target a GT-I9000 on Eclair, you'll need to customize one thing :
In build-update-zip.sh, set DROID_HOME to the source code path for your local Android repository.
Click to expand...
Click to collapse
quick question, the build-update-zip.sh is not a must if i only want to flash zImage, rite?
looks like that, I need to modify updater-script (if needed), as well as putting a zImage into ur zip file, and finally remove the build-update-zip.sh from ur zip attached
then, ur zip file can be used for flashing
is it correct?
thx
So this will let people flash any rom from an update.zip (once the ROM makers take this into account) via RomManager without ever having to use Odin to get off stock?
Awesome!
Thanks for the update script curio! this looks great.
One quick question - ive noticed several update.zip scripts for the galaxy S
have update-binary included.
Does anyone know what that does?? where did you get yours?
ive had success in using update.zips without that file at all.
Could anyone post information on what that binary is/does?
supercurio said:
Hey
Is Flashing from update.zip the new trend ?
'Don't know but here is how you can do it quite easily using this template.
If you target a GT-I9000 on Eclair, you'll need to customize one thing :
In build-update-zip.sh, set DROID_HOME to the source code path for your local Android repository.
If you target another Galaxy S phone or another version of Android, you'll need to adjust ro.hardware and ro.build.id properties accordingly.
This template is done for Linux/Unixes/OSX.
If Linux cost too much for you or your employer, please contribute by sending a .bat equivalent to the .sh
Of course, you also need to put a valid zImage to replace the template's empty zImage
Feel free to adjust to your needs. License is BSD anyway.
Note : requirement are Java and Android source repo, already build.
I'll add some documentation later.
Click to expand...
Click to collapse
dseo80 said:
Thanks for the update script curio! this looks great.
One quick question - ive noticed several update.zip scripts for the galaxy S
have update-binary included.
Does anyone know what that does?? where did you get yours?
ive had success in using update.zips without that file at all.
Could anyone post information on what that binary is/does?
Click to expand...
Click to collapse
Thats for the updater-script i believe. In most cases, theres a update-script in the zip's as well and the recovery picks that up in which case it doesn't need the binary and hence works.
Okay !
Answers hour
ykk_five said:
quick question, the build-update-zip.sh is not a must if i only want to flash zImage, rite?
looks like that, I need to modify updater-script (if needed), as well as putting a zImage into ur zip file, and finally remove the build-update-zip.sh from ur zip attached
then, ur zip file can be used for flashing
Click to expand...
Click to collapse
When you run ./build-update-zip.sh,
- it produce a temp zip file containing appropriate files in it.
- then there'is the signature part, building another .zip, ready to be used.
- this "final" update.zip is put in the same current directory and you can use it as it is.
No further complication
Brantyr said:
So this will let people flash any rom from an update.zip (once the ROM makers take this into account) via RomManager without ever having to use Odin to get off stock?
Awesome!
Click to expand...
Click to collapse
Yes, to flash a complete ROM (several partitions) one more thing is needed.
On command line, redbend_ua accept only one command.
In order to run several commands successively (ie flash multiple partition like Odin does), you'll need to write them in a file.
The file /cache/ota/command should do the trick, but it's untested right now.
There may be other method to prevent rebooting after flashing (hacking the redbend_ua binary, finding the appropriate command line option or removing the reboot command temporary)
dseo80 said:
Thanks for the update script curio! this looks great.
One quick question - ive noticed several update.zip scripts for the galaxy S
have update-binary included.
Does anyone know what that does?? where did you get yours?
ive had success in using update.zips without that file at all.
Could anyone post information on what that binary is/does?
Click to expand...
Click to collapse
Right, many update.zip done today are made without knowing anything about how it really works
I studied a bit before creating mine, here is a walk-through this fairly undocumented process :
- recovery mounts /sdcard/
- recovery search for a default file named : META-INF/com/google/android/update-binary in the zip and runs it : see the source in bootable/recovery/install.c
- update-binary is actually updater in sources
- updater looks into the zip file to the script file named updater-script, update-script is obsolete
- updater then runs the commands listed in updater-script : here is the list of commands.
- then reboot
The only documentation I know for this command is the recovery/updater/install.c file itself
supercurio said:
When you run ./build-update-zip.sh,
- it produce a temp zip file containing appropriate files in it.
- then there'is the signature part, building another .zip, ready to be used.
- this "final" update.zip is put in the same current directory and you can use it as it is.
Click to expand...
Click to collapse
ok,thx
but one more thing i want to know is, u said the path must be changed to the android repo, so do u mean the source code for the kernel like linux-xxx-2.xxx dir?
Thx
@ykk_five
Content of build-update-zip.sh v1 :
Code:
#!/bin/sh
DROID_HOME="/home/curio/dev/mydroid"
zip -r /tmp/update.zip META-INF/ redbend_ua zImage
java -jar \
$DROID_HOME/out/host/linux-x86/framework/signapk.jar \
$DROID_HOME/build/target/product/security/testkey.x509.pem \
$DROID_HOME/build/target/product/security/testkey.pk8 \
/tmp/update.zip update.zip
rm /tmp/update.zip
adb push update.zip /sdcard/
DROID_HOME="/home/curio/dev/mydroid" : you set here the directory of your Android AOSP directory.
See : http://source.android.com/source/download.html
Create an empty directory to hold your working files:
$ mkdir mydroid
$ cd mydroid
Run "repo init" to bring down the latest version of Repo with all its most recent bug fixes. You must specify a URL for the manifest:
$ repo init -u git://android.git.kernel.org/platform/manifest.git
* If you would like to check out a branch other than "master", specify it with -b, like:
$ repo init -u git://android.git.kernel.org/platform/manifest.git -b cupcake
Click to expand...
Click to collapse
This is this mydroid directory
The one that contains Android git source home directory, and compiled files in the out/ subdir
many thx for ur detailed explanation, supercurio!
Thanks curio,
very helpful explanation!
Thanks supercurio for the template!
However, there is no need to spend many hours (depending on hardware and bandwidth) pulling down 100s of megabytes of source and compiling it all if all you want is to sign an update.zip with test keys (if you already have the zImage)!
Just google around for "signapk.jar test keys" and you will get there.
BTW: I know that koush, leshak and wesgamer have Samsung Galaxy S trees up at Github but are they fully merged with AOSP yet?
I'm planning to go build my own kernel for this beast to try to solve the mono FM radio mystery, but last time I checked around it was said that the SGS tree required the use of a custom toolchain to get it to work at all.
Any comments on this?
Hey miki4242 !
Good to know that signapk.jar doesn't require hundred of megs of dependencies
About toolchain, you can use the one indicated by Samsung (CodeSourcery) but you'll face the big and ugly WakeLag.
I recommend you crosstool-ng or buildroot to build toolchains, with gcc 4.3.x march=arm mcpu=cortex-a8 mtune=cortex-a8 (no 4.4.x with march=armv7-v)
The building tutorial will be a part of the documentation I'll publish with my lagfix opensource release
Right now these info are too hard to find.
PS : I send you a mail with attached .config for ct-ng !
supercurio said:
Hey miki4242 !
Good to know that signapk.jar doesn't require hundred of megs of dependencies
Click to expand...
Click to collapse
supercurio said:
PS : I send you a mail with attached .config for ct-ng !
Click to expand...
Click to collapse
Thanks for the info !
Sorry for my ignorance, but does this mean someone can package Froyo in an update.zip and we could update it directly on our phone without needing Samsung Kies or Odin?
@supercurio:
Thanks for this well working template.
In updater-script:
Code:
line 17: package_extract_dir("zImage", "zImage");
should be
Code:
package_extract_file("zImage", "zImage");
But it did work with package_extract_dir, for some reason, too.
Btw, could you send me the config for ct-ng ?
I'm also struggling with this wakelag.
Good evening. I am having a sort of difficult time 'trying' to figure this out.. I have downloaded JB4.2.2 from source for the maguro, also CM10.1. Both have successfully finished the process [.imgs/ .zip] files. I have gone through the whole thing with downloading pdroid2.0 /syncing, etc. I have the sources for JB in /android/source and CM in /android/system. Including PDroid2.0 in CM worked out fine _followed the instructions_ and everything eventually came together. When doing the same for the JB source it doesn't complete. On first make of the source into four .img files/ then I made an ota.zip. Pdroid wasn't included. Anyone have any insight or advice?
Did you "make clobber" before buliding again? Also, you realize that you only get the "framework" and need to install the app as well (that's what happened when I was installing OpenPDroid). BTW why use Pdroid2.0 and not OpenPdroid?
My Gnexi said:
Did you "make clobber" before buliding again? Also, you realize that you only get the "framework" and need to install the app as well (that's what happened when I was installing OpenPDroid). BTW why use Pdroid2.0 and not OpenPdroid?
Click to expand...
Click to collapse
No, I didn't . Thanks. There are two separate guides for fedora I've been referring to and only one had the command you mentioned... And about the .apk, I got that after my first successful build. I wanted to give PD2.0 a try and that involves building from source. And I wanted to do that for a first time.
So you compile a rom yourself and add opd? Instead of the auto_patcher?
Yes I compile AOKP with OpenPDroid. Patching instructions are here: http://forum.xda-developers.com/showpost.php?p=36679267&postcount=4
After flashing install Pdroid Manger (from xda or Play Store). If you want to include it in the ROM (like if you want to publish the ROM for others to download), see part 8 of this guide: http://forum.xda-developers.com/showthread.php?t=2217175
BTW: "make clobber" will remove the outputs of the build, for example when you type "brunch" .java files will compile into .class-es (among other things), when you type "make clobber" it will delete the .class files.
Sometimes after making certain changes you will need to "make clobber" or they won't work.
I've observed that some modules source code have system package specific imports
example:
Code:
import com.android.systemui.statusbar.BaseStatusBar;
import com.android.systemui.statusbar.NotificationData;
import com.android.systemui.statusbar.NotificationData.Entry;
I've picked this code from serajr blurred systemui module.
I'm using android studio but even in eclipse I cant import them
but I've tried lots of methods but I coudn't find a way for importing it, it says that it's not there, can someone help me please?
thank you
Depends on the SDK version you're targeting.
If I recall correctly before Lollipop (or maybe KitKat?) you could simply import system classes by adding private Andoid libraries to classpath in your IDE.
But for never Androids you need to move all your Class loading to handleLoadPackage in the module because of ClassLoader changes, or else your module isn't gonna work even if it compiles right.
XspeedPL said:
Depends on the SDK version you're targeting.
If I recall correctly before Lollipop (or maybe KitKat?) you could simply import system classes by adding private Andoid libraries to classpath in your IDE.
But for never Androids you need to move all your Class loading to handleLoadPackage in the module because of ClassLoader changes, or else your module isn't gonna work even if it compiles right.
Click to expand...
Click to collapse
I solved it by adding the hidden libs and decompiling systemui, picking the dex file, converting it to jar and adding provide dependency on android studio, but thanks anyway
Xiaomi Poco F1 [ROM] [8.1.0] ResurrectionRemix v6.2.1
I installed xposed v90beta3, I can not start the module, it gives an error.
Help solve the problem
zygote64(3278): ClassLoaderContext size mismatch. expected=1, actual=2 (PCL[] | PCL[];PCL[/data/dalvik-cache/xposed_XResourcesSuperClass.dex*2802528989:/data/dalvik-cache/xposed_XTypedArraySuperClass.dex*708326108])
I am new to Xposed development. I figured out that we can override most methods in android. And from a famous tutorial I found out a way to change the clock to a smiley. Now, that android source code was different and My device's source code is different. I have a sony xperia z5. How do I reasearch my z5's 6.0.1 java code so that i can come up with a new xposed module??? Like where do I find my device's source code?
Please helpp......
thetitanium said:
I am new to Xposed development. I figured out that we can override most methods in android. And from a famous tutorial I found out a way to change the clock to a smiley. Now, that android source code was different and My device's source code is different. I have a sony xperia z5. How do I reasearch my z5's 6.0.1 java code so that i can come up with a new xposed module??? Like where do I find my device's source code?
Please helpp......
Click to expand...
Click to collapse
If OEM of your device does not provide source code repositories, the only way is to use apktool to decompile existing system components (e.g. SystemUI.apk for status bar). You'll get decompiled source in smali format which is quite hard to read and makes reverse engineering complicated. There are also tools which can convert smali to better looking representation which is close to java code but you still won't get the exact source code from which system was built. But it should give you basic info where your hooks have to be applied. In the past, I tried using Virtuous Ten Studio which is an all-in-one tool for reverse engineering but it was a long time ago thus not sure what the current state of the project is.
C3C076 said:
If OEM of your device does not provide source code repositories, the only way is to use apktool to decompile existing system components (e.g. SystemUI.apk for status bar). You'll get decompiled source in smali format which is quite hard to read and makes reverse engineering complicated. There are also tools which can convert smali to better looking representation which is close to java code but you still won't get the exact source code from which system was built. But it should give you basic info where your hooks have to be applied. In the past, I tried using Virtuous Ten Studio which is an all-in-one tool for reverse engineering but it was a long time ago thus not sure what the current state of the project is.
Click to expand...
Click to collapse
Thanks a lot! Ya I decompiled the apks and found some pointers that helped me a lot. Ya, sony provides developer sources but I was unable to convert the code into readable format... Can you help me with that?
Here is the link.... https://developer.sonymobile.com/do...rchives/open-source-archive-for-44-1-a-0-169/
thetitanium said:
Thanks a lot! Ya I decompiled the apks and found some pointers that helped me a lot. Ya, sony provides developer sources but I was unable to convert the code into readable format... Can you help me with that?
Here is the link.... https://developer.sonymobile.com/do...rchives/open-source-archive-for-44-1-a-0-169/
Click to expand...
Click to collapse
I'm not sure what that package contains since I did not download it due to its size but it's a packed image. You have to unzip and untar to get to the files.
Got it! Thanks anyways @C3C3C076. All I had to do was pull boot.oat and then use oat2dex. This gave me several dex files, and then there was this beautiful framework.dex and framework-classes.dex. The two things I needed to do look into.