Related
I started using Google ION ROM rev1 last week and I have been very happy. Question is, why is it so much faster and lag free than the standard G1 ROM? I was on JF 1.51 before this and it was very laggy. Also, I first tried Google ION ROM rev2 and I didn’t see any speed improvement.
Is Google ION ROM missing anything? If not, why wouldn’t Google optimize the G1 ROM to be this fast?
The first person to say something about a different version of DalvikVM is getting punched in the face
It's because it's a nice, clean build of AOSP 1.5r2 with no extra bull**** installed, thats all.
whats a DalvikVM?
j/k! "Ducks as cyanogen swings:
P.S. Luvin your work cyanogen, thank you sincerely.
and its not because it has pre-generated odex files either.
Its all kernel optimization I believe.
dwang said:
and its not because it has pre-generated odex files either.
Its all kernel optimization I believe.
Click to expand...
Click to collapse
Nope, the kernel is msm_defconfig (you can pull /proc/config.gz and compare for yourself), right from AOSP with zero changes.
cyanogen said:
Nope, the kernel is msm_defconfig, right from AOSP with zero changes.
Click to expand...
Click to collapse
Ok, it must be "magic" then.
dwang said:
Ok, it must be "magic" then.
Click to expand...
Click to collapse
I installed ion, I dont think its any faster than any of cyanogen's roms
defconoi said:
I installed ion, I dont think its any faster than any of cyanogen's roms
Click to expand...
Click to collapse
same here
salamandar said:
whats a DalvikVM?
j/k! "Ducks as cyanogen swings:
P.S. Luvin your work cyanogen, thank you sincerely.
Click to expand...
Click to collapse
DalikVM is a virtual machine created by some guy at Google.
http://en.wikipedia.org/wiki/Dalvik_virtual_machine
defconoi said:
I installed ion, I dont think its any faster than any of cyanogen's roms
Click to expand...
Click to collapse
I havent tried any cyanogens ROMs yet. I may have to give one a try, its based on JF 1.51, right?
defconoi said:
I installed ion, I dont think its any faster than any of cyanogen's roms
Click to expand...
Click to collapse
alapapa said:
same here
Click to expand...
Click to collapse
Did you install rev1 or rev2?
It's the dalvikvm combined with the .odex optimizations.
afflaq said:
It's the dalvikvm combined with the .odex optimizations.
Click to expand...
Click to collapse
did u even read the entire thread. Not its not.
dalvikvm in ion is exactly the same as j1.5.
android already does dexopt automatically on the dex files in the dalvik-cache. You can see it in the logcat whenever you change kernels.
All the stuff that people are doing to their ROMs are basically all placebo effect. The additional speeds that people are getting is from using cyan's boot.img.
I used ION for a few weeks, actually just started using Cyanogen's newest. I don't really notice much, if any, speed difference between the two. Same with Dude's latest ROM.
I do believe ION is all about the optimization (default CPU is 384mhz, not 528 on G1 port). ION was just optimized as much as possible to run the same speed on a slower processor. At least that's my take on it.
androidmonkey said:
Did you install rev1 or rev2?
Click to expand...
Click to collapse
both
(10 char minimum)
afflaq said:
It's the dalvikvm combined with the .odex optimizations.
Click to expand...
Click to collapse
See here about DalvikVM: http://forum.xda-developers.com/showpost.php?p=4021692&postcount=3791
It's snake oil. I don't know how or why people (and ROM developers) are spreading this idea. It's just plain wrong.
Then read this about dexopt (particularly the "preparation" section): http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/dexopt.html;hb=HEAD
Those .odex files are the exact same thing that is generated by the runtime in dalvik-cache. Now, it *is* possible that accessing resources inside of an apk where the original classes.dex has been removed could be slightly faster due to smaller size, but the zip format is designed to be seeked on so I don't really buy this either.
cyanogen said:
See here about DalvikVM: http://forum.xda-developers.com/showpost.php?p=4021692&postcount=3791
It's snake oil. I don't know how or why people (and ROM developers) are spreading this idea. It's just plain wrong.
Then read this about dexopt (particularly the "preparation" section): http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/dexopt.html;hb=HEAD
Those .odex files are the exact same thing that is generated by the runtime in dalvik-cache. Now, it *is* possible that accessing resources inside of an apk where the original classes.dex has been removed could be slightly faster due to smaller size, but the zip format is designed to be seeked on so I don't really buy this either.
Click to expand...
Click to collapse
Had the forums let me enter that in all caps to show my sarcasm I would have... /bonk
afflaq said:
Had the forums let me enter that in all caps to show my sarcasm I would have... /bonk
Click to expand...
Click to collapse
I realized that after I posted, but the points made are still true.
aFLACK!!!!
Again, it's not the dalkvik vm, or the odex files, or the smaller rom (not much actually, only a few files smaller than an adp google rom), it's the combination of the three plus a few other factors.
Dwang, you keep waving that flag that the dalvik vm does dexopt at the dalvik-chache, yet you're still failing to realize that IT IS DOING DEXOPT AT THE DALVIK CACHE... if the files are pre-odexed, the VM doesn't even do that. The dex at dalvik cache are not optimized, they're still dalvik bytecode, dalvik does this to prevent parsing the whole apk at app runtime and wasting time with both storing the dex to phone memory (which is already limited), and then running dexop at the extracted bytecode (because, as you correctly pointed out the other day, dalvik doesn't do jit, so .dex is quite useless to it),
with odexed files, you're saving both of those steps, the device just executes the .odex as needed without having to load to phone memory (thus linux's memory management doesn't kick in and dump, for example, home screen memory, explaining why you can return to home so quick). On T-Mobile's and google's roms, it goes an extra step by removing the .dex file from the apk, that way, when the machine still has to decompress the .apk file, it doesn't have to load such a big file to memory or check it all.
I don't think there's any sort of device specific modifications, since those would have been meant for the Ion and would break once running in Dream, unless it was haykuro that put them there, in that case, we're barking up the wrong tree and have to ask him what he did, but as I remember, it was actually him who broke ion with r2, so i guess that's not it either.
Nobody really knows why it works the way it does (and in some cases, doesn't work), but the combination of those three things i mentioned DO have an effect on how much work the phone has to do and how fast it can do it. Come on guys, it's all basic stuff...
What? Can people please read the entire thread before posting. Geez.
Its been established that the dalvik vm in ION is EXACTLY the same as in JF 1.5.
And, the dex files in dalvik-cache are optimized. Every time I load a new kernel, the dex files in dalvik-cache get re-generated.
Plus, cyan pointed to this link that says that it is:
http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/dexopt.html;hb=HEAD
So its neither dalvik vm nor odex files that is contributing to the speed.
jubeh said:
Again, it's not the dalkvik vm, or the odex files, or the smaller rom (not much actually, only a few files smaller than an adp google rom), it's the combination of the three plus a few other factors.
Dwang, you keep waving that flag that the dalvik vm does dexopt at the dalvik-chache, yet you're still failing to realize that IT IS DOING DEXOPT AT THE DALVIK CACHE... if the files are pre-odexed, the VM doesn't even do that. The dex at dalvik cache are not optimized, they're still dalvik bytecode, dalvik does this to prevent parsing the whole apk at app runtime and wasting time with both storing the dex to phone memory (which is already limited), and then running dexop at the extracted bytecode (because, as you correctly pointed out the other day, dalvik doesn't do jit, so .dex is quite useless to it),
with odexed files, you're saving both of those steps, the device just executes the .odex as needed without having to load to phone memory (thus linux's memory management doesn't kick in and dump, for example, home screen memory, explaining why you can return to home so quick). On T-Mobile's and google's roms, it goes an extra step by removing the .dex file from the apk, that way, when the machine still has to decompress the .apk file, it doesn't have to load such a big file to memory or check it all.
I don't think there's any sort of device specific modifications, since those would have been meant for the Ion and would break once running in Dream, unless it was haykuro that put them there, in that case, we're barking up the wrong tree and have to ask him what he did, but as I remember, it was actually him who broke ion with r2, so i guess that's not it either.
Nobody really knows why it works the way it does (and in some cases, doesn't work), but the combination of those three things i mentioned DO have an effect on how much work the phone has to do and how fast it can do it. Come on guys, it's all basic stuff...
Click to expand...
Click to collapse
Ok guys i've managed to successfully install the LiveWallpapers.apk from the NeXus dump and also the MagicSmokeWallpaper.apk on the G1 on android 2.1. problem is that I can't get the LiveWallpaperPicker.apk to install in order to use live wallpapers. reason being is because it isn't being deodexed properly.. I used the deo-all tool and it de-dexes the .apk but i see that it throws an error during the process and i can't find out what it is since the terminal quits to quickly for me to do so. i sign the .apk and install, but throws the error "dexopt". so my theory is its not properly being de-dexed.. once I get this solved i'll also have the new launcher2.apk, gallery3d.apk, and visualization wallpapers.apk able to be installed.
any help??
bump this get this poppin
I liked to see those apps working as well...
Major progress, so thanks to a cpl devs who helped out (miketaylor, djengizz) i've been able to install the livepaperpicker.apk and the prompt to use live wallpaper shows up now.
but it fc's. reason being is because for some odd reason when it gets deodexed the mainclass in the classes.dex gets deleted and so the activity can't be read and it isn't initialized by dalvik. all we would need is to be re-compile the classes.dex back with the mainclass and in theory it should work.. but that's where the problem lays. smali isn't being so nice and throws bunch of errors.
ive heard talk about these wallpapers. what exactly is so special about them?
[email protected]@ said:
ive heard talk about these wallpapers. what exactly is so special about them?
Click to expand...
Click to collapse
From what i've seen they allow the wallpapers to be animated, so for example, you can have a wallpaper that has different weather effects, or a pic of the ocean moving etc.
I cant wait until this is working on the Manup 1.0.1 rom.
good luck guys, this would be amazing.
update: there's just 1 issue holding this back from happenning afaik, once we get this worked out it should be a go.
jroid said:
update: there's just 1 issue holding this back from happenning afaik, once we get this worked out it should be a go.
Click to expand...
Click to collapse
Thanks for your feedback
Hope you can tune the app soon!
Maybe something is wrong with the app that you been trying to deodex. Have you tryed downloading another nexus dump from a different source and deodexing those apps? Just a suggestion in case you didnt think about it just trying to help!
i am trying to install this on my droid with 2.1.
You need to move over some of the libraries from 2.1 or else it will not work.
iamkewl said:
i am trying to install this on my droid with 2.1.
You need to move over some of the libraries from 2.1 or else it will not work.
Click to expand...
Click to collapse
ok like what libs??.. my main issue right now is when de-odexing the apk, it leaves out the mainclass activity, so it cannot be initialized by dalvik and throws a fc. I've got it installed however and attempts to intialize when prompted
jroid said:
ok like what libs??.. my main issue right now is when de-odexing the apk, it leaves out the mainclass activity, so it cannot be initialized by dalvik and throws a fc. I've got it installed however and attempts to intialize when prompted
Click to expand...
Click to collapse
Maybe he is talking about this lib's:
http://www.alldroid.org/viewtopic.php?f=210&t=850
"lib files - http://www.megaupload.com/?d=BFIEKPH3"
anthonws said:
Maybe he is talking about this lib's:
http://www.alldroid.org/viewtopic.php?f=210&t=850
"lib files - http://www.megaupload.com/?d=BFIEKPH3"
Click to expand...
Click to collapse
will look over these files. thank you
jroid said:
will look over these files. thank you
Click to expand...
Click to collapse
Any Progress on this...ill be a beta tester if you need any
this is one of the coolest features of 2.1 to be honest...the eye candy factor is amazing. Seems like progress is being made though...you think it will be done soon? want it on my mt3g soon =D
guys, I have everything I need to get this working, it's just I still have the 1 problem that is totally hindering this. i'ved asked for help to somebody but they haven't responded back, although it's not something that me and djengizz haven't tried already. at this point, only hope we have is getting an un-odexed dump, OR jf updating the smali tools that are throwing the errors that we get. believe me, if u guys can't cait to have this, imagine how i feel having everything set and ready to go with only 1 thing holding it back, especially since I was basically the first 1 to start up on this mod before anyone else.
Sucks I cant do anything to help...im just sitting down while you do all the work so I can watch my wallpaper move
sounds like your really trying hope you get this out soon...you'll be my hero for sure.
basically, the main problem is in smali... I have all the smali files and try re-assembling but smali just throws loads of erros and doesn't make the classes.dex we need to get this up and running.
To save me "re-inventing the wheel" can any one advise me on the propriety files needed from the N1 to build a custom ROM for it? e.g. libhtc_acustic.so and libhtc_ril.so
I am trying build a ROM from the open source project, so if anyone has advice for me please let me know.
Before you ask, the only reason i am doing this is because i have system apps i want to try on it and they need to be signed with the same key as the shared system uid. If you no a way i can build a ROM from the Nexus to do this please let me know.
Ne0
I don't believe the 2.1 source has hit the AOSP repos yet. So you won't be able to build a complete framework/kernel until that is released.
You could dump your N1 and then just unarchive and resign everything, but it would be a hell of a job I think
I realise 2.1 is not a public resource yet, but i am attempting to roll back to Eclair, just for the purpose of testing my system apps.
I want to resign everything and i dont mind if its a hell of a job!! What do you mean by unarchive? and whats the best way to get a complete dump?
Thanks for your help.
Ne0
Roll back to eclair won't work. The binary blob drivers are tied to a kernel and the kernels are (kinda) tied to the platform releases. So the N1 can only house 2.1 right now (IIRC)
What I was alluding to is that each APK/JAR contains a signature that you want to replace with a sig made by the test keys right?
So if you pulled /system from you're N1 and re-signed each apk and the framework with test keys and pushed that back or made and update.zip holding the re-signed apks (like the theme-makers) you should then be able to test your platform app that is also signed with test keys and a shared UID.
I too would like to know the answer to this.
SilentMobius said:
Roll back to eclair won't work. The binary blob drivers are tied to a kernel and the kernels are (kinda) tied to the platform releases. So the N1 can only house 2.1 right now (IIRC)
What I was alluding to is that each APK/JAR contains a signature that you want to replace with a sig made by the test keys right?
So if you pulled /system from you're N1 and re-signed each apk and the framework with test keys and pushed that back or made and update.zip holding the re-signed apks (like the theme-makers) you should then be able to test your platform app that is also signed with test keys and a shared UID.
Click to expand...
Click to collapse
SilentMobius said:
I don't believe the 2.1 source has hit the AOSP repos yet. So you won't be able to build a complete framework/kernel until that is released.
You could dump your N1 and then just unarchive and resign everything, but it would be a hell of a job I think
Click to expand...
Click to collapse
Correct ... resigning everything with test keys would enable some1 to test out said system apps (also signed with testkeys) ... but only as a test, as it would not be suitable for everyday ROM use.
Resigning with test keys is trivial (search for it) ... but I'd recommend you use the de-odex'd system (see the nexus1 theme templates in my sig).
The reason this is not a everyday solution is b/c resigning everything with testkeys will break the google checkin process, meaning signing into google and using the market will largely break.
But if this is truly just for some sorta system app test, that shouldn't matter.
Other than that, the OP's question is fairly broad in scope. A question like "how to create a custom ROM for nexus1" ... implies many things and many answers.
~enom~
enomther said:
Resigning with test keys is trivial (search for it) ... but I'd recommend you use the de-odex'd system (see the nexus1 theme templates in my sig).
The reason this is not a everyday solution is b/c resigning everything with testkeys will break the google checkin process, meaning signing into google and using the market will largely break.
~enom~
Click to expand...
Click to collapse
Thanks enom, great work. My system apps are just for testing, though it would be handy to make it into a complete ROM so i dont have to keep reflashing when i need to use them. Are you saying that it is not possible to get google checkin working this way? or just that no one has done it yet?
Ne0
Just resigned, sync'd with google, market works and i can install my system apps. All thanks to ~enom~, thanks for posting the deodexed system, saved me a bit of time!
Well hello everyone.
I am an application development student from Belgium.
I am proficient in Java, VB.NET, some c/c++ and also PHP/JS/HTML/CSS
Anyways, my recent interest has been going out to creating custom roms for the galaxy S!
The problem now is though, I was able to find some guides and such, but most were incomplete, and for HTC(and other) devices.
I have no idea what is different between making a ROM for galaxy S or a ROM for an HTC device.
If anyone would like to link me to some good resources that can help me on my way, or would like to collaborate (and in the meanwhile teach me a bit) I would be more than happy! (I am open for collaboration as I am pretty proficient in Java and I'm always happy to code and learn more about coding!)
I think the question is really want you want to do!
Custom ROMs for Android are as simple as using recovery console to replace files on the system with your own versions.
ie. Replace the framework.apk which contains all theme images with your own modified one, which you can use to skin the device. Same for replacing other system apps.
Unfortunately, most of these apps are closed source, so modifying them is difficult. The stock android system has open source versions of most of them though, and you can modify those and build them, and then replace the ones on the device. I'm not entirely sure how to build them up though, but it probably isn't too hard.
Then there are custom kernels, which let you actually change the underlying linux system underneath android - Samsung has an open source version of the kernel available that you can compile, and then flash to your phone using Odin or other tools. Compiling the kernel is pretty tricky though.
Well i'm really talking about stuff like SamSet, MoDaCo, Doc's ROM and others.
I'm not saying I want to create a pro ROM in a day or anything, but i'd really love to learn more to get better (always looking for more stuff to put on the resume, I guess?!)
Thanks a lot,
Kenny
Bump for some help
(sorry for the double post but i'm really eager to learn)
I don't have time to give a detailed response right now. However you will want to read up on yaffs (file system) and odexing/deodexing ROMs.
Thank you I will definately do that,
I am following a guide now to start out creating custom ROMs for android, however it was written for Motorola Droid and I have no idea what you have to do different for a samsung galaxy s.
I am a good coder, even though I say so myself, with a lot of experience. I also have a lot of linux experience, you name it
Only the problem is the old, and much known "where do I get started?"
So if anyone can point me out in the right direction on that, tell me how/where you started out, I would appreciate it greatly!
Thanks!
Very sorry to bump again
I set up my environment in ubuntu today to get started (just gotta fix a few errors, didn't know android wouldn't compile on java 1.6, only on 1.5)
Anyways, still need some help here! thanks!
Again I am awefully sorry for the bump here but i'd really like some help.
Note that i'm not a newbie at coding whatsoever and i'm not unfamiliar with some hardcore java, c/c++ and other languages, I'm just having trouble getting started when it comes to modding an existing android release (there are tutorials on HTC and other devices but some methods do not apply to the galaxy S)
If you're trying to create a ROM from scratch then unfortunately you're out of luck at the moment. No one has really managed to do so yet. By "from scratch" I mean the Android Open Source Project (i.e. official Android git repository).
What you can do is grab an existing firmware. Extract the contents, de-odex the apks, modify them or add new apks, optionally you can also compile a custom SGS kernel using Samsung's kernel source. Then you can re-odex the ROM, pack it back up and distribute it.
There's no real "starting place" as such and you won't yet find any tutorials about how to create SGS ROMs. Just give it a go and see where you get.
Yes, I do mean creating a ROM from stock samsung firmware, of course.
So my next logical question would be now:
How do I go over extracting contents from the existing samsung firmware, de-odexing and so on?
Any links/guides/tips are greatly appreciated, as long as they are applicable to this cell phone and not totally crap, thanks!
Samsung uses rfs, I think you should know. There is a thread somewhere in this forum regarding extracting .rfs file. Understood you need Debian though.
For some readup, go search for a famous guy named JesusFreke. Tons of materials...
Hope that from here onwards, this can lead you on, and to find out more. Google is your friend too...
I'm afraid my biggest problems already occur in setting up the environment, so it's really the very beginning that gets me stuck, i'm sure coding would be a bikeride compared to setting up the environment for me (i'm no hero in linux,not at all, i'm afraid)
How the hell do I get from point A (being downloading the full source) to point B (starting to create a custom ROM?)
thanks
of course if anyone has the time, and wants to, you can PM me your msn or something, if anyone is up to it
Raykoid666 said:
I'm afraid my biggest problems already occur in setting up the environment, so it's really the very beginning that gets me stuck, i'm sure coding would be a bikeride compared to setting up the environment for me (i'm no hero in linux,not at all, i'm afraid)
How the hell do I get from point A (being downloading the full source) to point B (starting to create a custom ROM?)
thanks
of course if anyone has the time, and wants to, you can PM me your msn or something, if anyone is up to it
Click to expand...
Click to collapse
Agreed completely! Getting a full cross-compilation to Samsung's Android going is seriously difficult! There have been some promises for tutorials and guides for setting things up though, but none have appeared yet. Probably because it's hard!
Well thank you for agreeing with me on that.
I am really hoping for anyone that can help me out here, either on here or in private, and give some detailed instructions on how to get started.
Hell there is enough information on creating roms alread, deodexing, adding/removing apps etc etc etc... The real problem lies in setting everything up properly.
I think I have gotten to the point where I'm compiling the android source (without samsung specific files)
note i'm saying "i think i am compiling" because i'm hoping it won't error out on me again after an hour of compiling!
But once that is done... I have no idea where to go next, where to get the samsung specific files, or what to do with them whatsoever once i have them
thanks!
Android generic source won't actually help you much. Samsung has made a huge number of changes to it, and while it is all open source, backporting their changes to get your stock source running on the phone is a major undertaking. I believe cyanogenmod was actually working on this, but it seems without much success so far.
What the other rom makers you see are doing is taking a snapshot of a running rom, copying over all of the APKs and the files on a running device, and then tweaking those. ie. Opening up framework-res.apk and changing the image files inside.
The update.zip roms that are what most people are doing are really just using the Android recovery to replace files on the phone with their own versions. Since the underlying system is linux, and everything is a file, this actually works pretty well.
The kernel development effort is completely separate from the rest of the system though, and Samsung has provided the entire source tree that just has to be compiled. I'm a bit stumped myself on all the details of setting it up, but I have seen some threads on this forum about it, and it didn't seem too bad to set up. Apparently you shouldn't use the codesourcery toolchain though, or something. Not too clued up on it, sorry. Hopefully someone with the details can chime in, or give us a link to the old post on it (I'm failing to find it using the search function! )
Alright sounds good!
So these recovery files you are talking about (the contents of /system) how do i retrieve those from a base ROM such as JM7 or the likes after a clean flash?)
Raykoid666 said:
Alright sounds good!
So these recovery files you are talking about (the contents of /system) how do i retrieve those from a base ROM such as JM7 or the likes after a clean flash?)
Click to expand...
Click to collapse
Root your phone, zip them up onto the sdcard, and then copy them off.
There are probably better methods, but this works fine.
Also, with credits to Unhelpful, he has told me that the correct toolchain to be using is 'uClibc or eglibc toolchain with ct-ng'. I have no idea what to do with that yet, but it's a start.
RyanZA said:
Root your phone, zip them up onto the sdcard, and then copy them off.
There are probably better methods, but this works fine.
Also, with credits to Unhelpful, he has told me that the correct toolchain to be using is 'uClibc or eglibc toolchain with ct-ng'. I have no idea what to do with that yet, but it's a start.
Click to expand...
Click to collapse
You don't even need to root your phone to pull /system Ryan
adb pull /system <random folder>
is all you need ^^
Alright thank you, I managed to get all the /system files using abd pull /system
now next thing up would be de-odexing right, before I go editing stuff?
Now before I go de-odexing. Can anyone tell me what exactly de-odexing is and why I need it?
and what do I need to do to create an update.zip again?
thanks a lot all!
Tayutama said:
You don't even need to root your phone to pull /system Ryan
adb pull /system <random folder>
is all you need ^^
Click to expand...
Click to collapse
Haha cool, didn't know you could pull whole folders!
Raykoid666 said:
Alright thank you, I managed to get all the /system files using abd pull /system
now next thing up would be de-odexing right, before I go editing stuff?
Now before I go de-odexing. Can anyone tell me what exactly de-odexing is and why I need it?
and what do I need to do to create an update.zip again?
thanks a lot all!
Click to expand...
Click to collapse
The apk files in Android are odexed - that means they have a special index applied for dalvik that speeds them up somehow! I don't know how, I haven't checked how it actually works.
The important point is though:
odexed is faster, but you can't edit it because of signatures or something technical
deodexed means you can change it however you want
More useful info can be found from google - lots of it!
update.zip is easy - it's a zip file in a special format that can be understood by Android's recovery console. The easiest way to do it is to grab an existing update.zip and modify it as needed. Tayutama has millions of em around, so use his!
Then you need to sign it once you're finished with it so that the SGS will accept it. Samsung made a boo-boo and didn't disable the test keys for the 2.1 SGS firmwares. That makes it easy!
http://www.londatiga.net/it/how-to-sign-apk-zip-files/
Just use the test keys to sign it, and then copy it to /sdcard/update.zip and reboot into recovery and it'll work.
NOTE: This is a thread for the build devs.
Users who want to try this solution themselves should head over to TheAgent1982's thread: RTL Support Project, or go to the Hebrew guide at htcaddicts.com.
Update: Hey devs. Just so you'd know, we're even willing to do the framework.jar patching for you!
All we ask from you is to deodex your builds, and include the patched framework.jar (which appears to be almost the same for all builds, barring sense/non-sense differences).
PM if you're willing to let us help
Hey devs
First of all, thanks to all the devs who are doing a great work with everything!
There's one thing though that's a pox on all Android builds (even native android devices), and that is full-on right-to-left support. What do I mean?
Sure, there are Hebrew (and I assume Arabic) fonts in Android, and MOST applications work just fine, with the notable exceptions of Gmail, Google maps, and most native Google-apps, who all display Hebrew backwards.
A far more stressing issue, however, is that ALL android applications without exception display numbers backwards in right-to-left texts (so 10 becomes 01, 12 becomes 21, etc. It can get really confusing really fast).
Any way, there exists a solution for both these problems that can USUALLY be fixed with a medium amount of experience on native Android devices, but requires a bit of a hassle for HD2 owners.
Hopefully, you devs can incorporate this fix to future releases, once the fixed files are obtained it shouldn't be too hard to spread in the future.
Here's the process:
BTW, This only works on completely deodexed builds!
First, you have to download this zip file. It basically contains the fixed files and some other stuff you devs probably won't need.
The fix then involves extracting 'framework.jar' from the phone, and extracting the 'classes' file thusly:
Code:
java -jar baksmali-1.2.2.jar -o classes classes.dex
Then, in the subsequently created "classes" folder, you need to replace the files in "/classes/android/graphics/" and "classes/android/text" with the relevant files in the aforementioned zip file (from the corresponding folders, of course, under "files/froyo/")
After that is done, you need to re-create 'classes.dex' using:
Code:
java -Xmx512M -jar smali-1.2.2.jar classes -o classes_new.dex
Then, replace the old 'classes.dex' in 'framework.jar' with the new one (after renaming it back to 'classes.dex', of course), and push the new and fixed 'framework.jar' back to the phone.
Reboot, and voila: full-on Left-to-Right support!
I'm sure you devs have far better ways of including these fixed files without having to edit the entire thing every time, but what would I know?
We would be extremely appreciative to all you builds devs if you could incorporate those fixed 'classes' files in future builds, it'll save us a ton of work.
Also, if any of you guys also need volunteers for beta-testing this solution (as I'm sure you don't have Hebrew content to test it with), feel free to PM me.
Thank you for listening, and keep up the great work!
((PS, thanks to member silverbluem who helped simplify the process))
+1
i use the htc sense to read sms so
the msg wont appear word4 word3 word2 word1
+1 for that. although i am using bifbif ver 1.2 with CM6 and its OK here.
i've test it on Mdj Evolution 2.3 and it work perfect:
i never copied the files to /graphic only to /text folder
to put the Framework.jar in the device because we dont have recovery mode
use this commands:
to pull the file:
adb pull system/framework/framework.jar
install the attached files
adb push (your file location/framework.jar) system/framework/framework.jar
after putting the file restart the device
restart might take 5-10 min first run after applying the file
thanks
silverbluem said:
i've test it on Mdj Evolution 2.3 and it work perfect:
i never copied the files to /graphic only to /text folder
to put the Framework.jar in the device because we dont have recovery mode
use this commands:
to pull the file:
adb pull system/framework/framework.jar
install the attached files
adb push (your file location/framework.jar) system/framework/framework.jar
after putting the file restart the device
restart might take 5-10 min first run after applying the file
thanks
Click to expand...
Click to collapse
This sure does absolve us of needing to use Linux and needing all that messy system.ext2 stuff. I'll give it a try.
Still, it'd be nice to have these updated files already incorporated into future builds.
Ambious said:
This sure does absolve us of needing to use Linux and needing all that messy system.ext2 stuff. I'll give it a try.
Still, it'd be nice to have these updated files already incorporated into future builds.
Click to expand...
Click to collapse
still need to figure out how to replace the graphic file
cause the view is not perfect without it...
Ambious said:
Edit: I tried this method, and while it DID boot, the solution didn't work - numbers still backwards, Google applications still reverse.
Click to expand...
Click to collapse
what rom are you using?
EDIT: the only thing that need to change to you is the phone book is now need to be RTL and the number backwards
Gmail need the Graphic file
silverbluem said:
what rom are you using?
EDIT: the only thing that need to change to you is the phone book is now need to be RTL and the number backwards
Gmail need the Graphic file
Click to expand...
Click to collapse
My WM rom is OzDROID2.0, my Android rom is MDJ FroyoHD 3.7
Well, the phone book was never a problem for me, only hybrid text/numbers like in text messages etc.
Anyway, turns out I didn't modify framework.jar correctly, so I tried again using the script, and this time the phone just won't boot (like when I used Linux, it just hangs at boot screen).
Edit: Tried all day, all combinations of 'texts' files and with or w/o the 'graphics' file, and it always either just didn't fix anything (when I did the fix manually), or didn't boot at all (when I tried the script). This got me to conclude that I must not be doing it right, or else it would fail to boot for me as well (at least, I'm not even considering me being able to totally fix it myself )
Not a week ago, i was referred to the Samsung Galaxy S's newest ROM which came from Orange..
The rom includes (to my understanding) all the latest fixes regarding left to right text and even a hebrew version of Swype
It is easily retrievable. Obviously, it isn't legal to extract their work and use it to manutfacture a widespread ROM... but you can use it for personal use if you want to check how to fix that annoying hebrew thing.
+1000
Thanks
nir36 said:
Not a week ago, i was referred to the Samsung Galaxy S's newest ROM which came from Orange..
The rom includes (to my understanding) all the latest fixes regarding left to right text and even a hebrew version of Swype
It is easily retrievable. Obviously, it isn't legal to extract their work and use it to manutfacture a widespread ROM... but you can use it for personal use if you want to check how to fix that annoying hebrew thing.
Click to expand...
Click to collapse
It COULD be used to reverse engineer some of the stuff, but I doubt it's similar enough to the HD2 builds to use it.
+1
Thanks
Hebrew RTL Support
For those who are asking, i have made a working framework.jar , time ago.
It is working for most FROYO Sence, CM6.+ does not need it...
BUT NOT Desire HD Sence ( Because is is odex files, not only *.jar).
If needed i will upload it, and put a tutorial how to make it work...
Good Day!
RTL HEbrew
Please do that !
Thanks
Framework.jar
Tomorrow i will post the file with short tut how to put it, i must say that Ambious bring a good tut directly from iAndroid
Any way, Ambious, if i will upload the file please stick it to 1st page.
For now, good night...
This fix is a must for all RTL language users.
As mentioned, CM6+ already includes the fix and is working pretty good!
Problem is, for some reason, CM6 builds are rare...
I tried a few Sense builds but eventually i came back to a CM6 based build
because of it's support for RTL languages.
Devs, please include this fix in you builds, to make them as much accessible
as possible.
Thanks.
TheAgent1982 said:
Tomorrow i will post the file with short tut how to put it, i must say that Ambious bring a good tut directly from iAndroid
Any way, Ambious, if i will upload the file please stick it to 1st page.
For now, good night...
Click to expand...
Click to collapse
I sure will!
Thank you
However, as a Sense user myself, I'm pretty anxious to see if a fix can be applied to any of the Sense builds (especially DesireHD, which is my current build).
Well Organized Post
I have made well organized post for it:
RTL Support Post.
I must say, it will NOT Work for Desire HD for now, because it is ODEX and jar combined, and as you have read at iAndroid, for now there is NO solution for it,
and i do not have the experience and time to learn and convert it, since i am a student.
But i will give it a try between the semesters...
Hey,
The HD2 Desire HD builds are fully deodexed.
Froyo HD 3.7 for example: http://forum.xda-developers.com/showthread.php?t=795914
Maybe you could use them for preparing a RTL fix for when the deodexed desire HD ROMS come and for us HD2 android users.
Cheers.
It may be my semi-n00bness, but all my attempts to create a fix for DesireHD 3.7 failed.
Also, trying the supplied fix in the thread above on MDJ Sense Clean (non HD based) failed, wouldn't boot.
Hopefully someone can get it to work, and better yet - that the devs will incorporate those fixes in their builds.