So you’ve got a nice, shiny, new G1 and you’ve been hearing about all the amazing things you can do with it but you “MUST HAVE ROOT”. As far as you know, you’re not a plant (although you may feel as smart as one at this point) and beyond that, you have no clue what any of the terms or concepts mean in context.
Well, I’m bored so I’m going to try and clear some things up.
There are a lot of threads that cover each of these things but I’m going to try and put as many basics into one post as possible. Hopefully it can be a perfect start for n00bs and good reference in lieu of search for others. Please feel free to correct any semantic (or blatant) mistakes I make.
I’ll keep the glossary here and update terms as I add to this post:
Android OS - Like Windows Mobile but based on Linux, using a Java based front end.
Linux - Open Source operating system used instead of Windows XP/Vista, Mac OSX etc... it's free (as in beer).
Open Source (From Wiki) – Free and open source software, also F/OSS, FOSS, or FLOSS (free/libre/open source software) is software which is liberally licensed to grant the right of users to study, change, and improve its design through the availability of its source code.
Root (as in access)- root is like the administrator account on a windows machine (also referred to as su, or superuser). It allows you to have complete access to the underlying OS of a linux or *nix based machine. For the G1, it allows for the use of themes, native backup functionality, manually selecting which apps can utilize root access, auto-rotate screen, multi-touch in browser, moving applications/caches to the sd card etc...
Root (as in location)- the 'root' of a folder or drive is the top most area of that location. In windows, C:\ is the 'root' of your hard drive. The 'root' of your SD card just means you haven't moved into any subfolders.
Shell – (also heard as terminal, bash, command line) This is a loose definition, but it’s basically a command line to run specific actions against the OS.
Bootloader – the SPL and IPL of a flash based device. See jashu’s description here.
SPL (Secondary Program Loader) - You get to the SPL by holding the camera button while powering on your phone. This is where you flash NBH images. See bootloader above.
Recovery Mode - Holding the 'Home' key while while powering on the G1 will take you into Recovery Mode. From here you can perform a NANDroid backup, wipe your phone, access a command line and of course, flash your phone with an update.zip file.
RC## (or release candidate) – In context to the G1, it is an official release of Android from T-Mobile meant specifically for the G1 (not ADP).
ADP (Android Developer Phone) – A Google specific (or carrier non-specific) version of the G1/Dream that has root access by default and is meant for developers writing apps for the G1, or Android in general.
ADP vs. RC## - Neither RC’s or ADP versions are tied to their respective hardware. With the right bootloader, you can flash an ADP image to a G1 or an RC image to an ADP.
JFV1.## - Is a specific Version of a JesusFreke ROM. JesusFreke is a developer on this website that has graciously spent his time to modify the G1 OS to allow us to have root access to our phones. This gives us the ability to explore and modify our phones via a command line.
Cupcake – a development branch of the Android OS that contains many improvements that was merged into the master build of Android and is currently being released to new phones as Android 1.5.
Nandroid – a utility, accessible through Recovery Mode, that allows you to backup your phone and restore to the exact condition at backup.
Apps2SD – Applications moved to your SD card instead of internal memory. Some people like the extra room, some people don’t want to hassle with the partitioning.
Partition – just like the partitions that separate cubicles in an office, a partition separates parts of a drive.
File system – there are many. It’s basically a specific way of organizing data on a partition. FAT(32) is generally windows, ext2 is generally linux. This is not a hard and fast rule, just most common in context with what you’ll see here.
Scripts – scripts are text files that contain a list of commands to perform. Instead of typing each command out multiple times, a script can be run that will initiate all steps listed in the script.
Android SDK (System Developer’s Kit) – This includes all tools (sans fastboot) that a developer needs to create applications for the G1. It also has tools for interacting with the phone via a command line (ADB).
ADB - is a part of the SDK that allows you to run commands against the G1 in lieu of using the terminal on the phone itself.
Fastboot - is a tool used to flash system images (.img files) to the G1 from a command line on your pc. IMG files are created when you do NANDroid backups and official images can be downloaded from HTC as well. To get to fastboot mode on your phone, hold the back button while powering on.
When T-Mobile first released the G1, they left a bug in the Android OS that allowed anything typed on the keyboard to be passed on to a root shell running in the background. This really was a major flaw and needed to be patched. Unfortunately, when they patched it, they really patched it. RC29 was the last version that still had root. With all versions RC30 on, it was removed. It completely denied us any hope at modding our “open-source” phone.
Somehow, the base image for RC29 (dreaimg.nbh) was leaked and some enterprising developers were able get access to the bootloader and return an updated G1 (RC30+) to RC29 and use this to regain root.
Somewhere along this road, Google released the ADP (Android Developer Phone), which has root enabled and uses a specific SPL (EngineeringSPL) that was the base for the modified HardSPL that most of us use now. Nandroid was included to allow us to back up our phones and shortly after, JesusFreke modified RC30 to keep root and still provide the fixes and improvements that came with it.
I’m not sure where it all started, but eventually, LucidREM released a modified version of JesusFreke’s ROM. This made moving applications to SD painless and freed up system storage and now we can have 32 flashlights and 62 tip calculators installed all at once.
Apps2sd has been the bane of many peoples existence. It requires you to partition your SD card in to separate file systems (FAT32 to remain compatible with windows computers as a mass storage device and ext2 to maintain compatibility with the underlying linux OS of the G1). It also requires you to move your apps to the SD card and then create symbolic links (similar to a windows shortcut) from the internal location pointing to the SD card. Lots can go wrong in this process and that’s why LucidREM, MartinFick, MarcusMaximus04 and others have created tools to help simplify the process.
Now of course, to achieve any of the things you want to do with the G1, you have to interact with it. There are at least 2 main ways to do this. Some prefer to do everything from the phone itself using a terminal, while some prefer to use their PC with the phone connected via USB. Others avoid both of these, as best they can, and use other peoples apps or scripts anywhere they can get away with it. This is why you may find many different explanations of the same goal.
In order to interact with your phone from a pc, you need the Android SDK, which includes ADB. ADB is basically a linux shell that communicates with the G1. It is easier to copy and paste from threads and insert commands without worrying about making typos. It also requires it’s own bit of hoops to jump through (unless you use a mac or linux ;-)) and sometimes scares people away. It is highly recommended if you plan on hacking at your phone with any regularity.
Of course, there are some sadists (I once was one) that like to type line after line of code on a tiny keyboard and use the terminal directly from the phone. This is fun and it makes you feel 1337, but it also leaves a lot of room for error. Remember, you are a root user now, and any mistake you make can be potentially huge.
Well, that’s all for now folks. Please feel free to add, subtract, reorganize, correct anything I’ve said, in the comments. Also, I’ve tried to add links to any relevant threads and sources that I used in making this… this, whatever you wanna call it.
Thanks to everyone in this community for doing what you do. We are all geeks and enjoy doing this stuff. It's good to have so many talented people taking an interest in Android and the G1 in general. It is open source communites that keep technology interesting and exciting.
Thanks to Haykuro, TheDudeofLife, all the theme devs, and all the big players that I didn't reference in this post. Oh, and SolemWishing for the Timeline! It helped, thanks!
Reserved for future posting
Awesome post for nuubs. This should be permanently stickied!
Very cool. a couple terms you should add:
Fastboot
SPL
Recovery mode
(including what key strokes you need to hit to get into spl and recov. modes)
Thanks for the feedback!
I added SPL and Recovery... let me get my facts straight on fastboot and I'll add that tomorrow.
I don't know if it is the right place for it, but there seem to have been lots of question about "radio" or more specifically "radio update".
I feel smarter already.
I particularly found the file system explanation useful, i put it together that fat32 and the other were the two partitions but didnt realize which was for cpu. Not ready to attempt but definitely closer (although Im not even sure if I want to partition i have no need for all that space at this point) It doesnt affect performance does it?
Agreed. Good stuff. Definitely noob required reading material.
Yes, indeed a very nice guide for the beginners. Hell we ALL started that way...i remember when I first got this phone ~6 months ago (no root), and there was almost nothing about it, no support, no add-ons, no hacks, nothing. It was boring, and for me I was coming from a motorola (motomodders?), so going to something that was far superior but didnt have community support made me almost cry.
Though look now, 3 months later the market was filling up and being abundent of new stuff to play with (I didnt even try rooting for a while, until it became a lot more well-known [fixes and the likes], and themes became a necessity because they started to get really good), and now 6 months later people are hacking away figuring out soo much stuff about it. Amazing work everyone, seriously.
Something good: It all starts at the roots .
Well, I added info on fastboot and exceeded my 10000 character limit. Now I understand why so many people reserve the second post. lol...
I'll make some changes so I can add info about the radio, however the link to fastboot explains the radio fairly well.
Thanks for the feedback everybody, I hope this helps some people out.
skri11a said:
So you’ve got a nice, shiny, new G1 and you’ve been hearing about all the amazing things you can do with it but you “MUST HAVE ROOT”. As far as you know, you’re not a plant (although you may feel as smart as one at this point) and beyond that, you have no clue what any of the terms or concepts mean in context.
Click to expand...
Click to collapse
When i read those lines i knew that this post would be worth reading
It was a really nice n00b guide, though ive done some WiMo flashing so some of the terms sounded familliar i certanly learned a thing or two
I would say it should be stickied and put on the wiki - oh and perhaps list it in alphabetic order, it would make it more usefull as a "I dont understand this term so ill just look it up"-thread...
Perhaps you can get a mod to give you post #2 & #3
//M
DMaverick50 said:
I feel smarter already.
I particularly found the file system explanation useful, i put it together that fat32 and the other were the two partitions but didnt realize which was for cpu. Not ready to attempt but definitely closer (although Im not even sure if I want to partition i have no need for all that space at this point) It doesnt affect performance does it?
Click to expand...
Click to collapse
I'm glad it helped. As far as performance issues, I've had none. In fact, when I was skating along with 12-19MB of free space, my phone would crall and cause me all sorts of grief. Since I've moved the apps and dalvik-cache, it's been very responsive and reliable. That being said, get a GOOD sd card. I see a lot of people having problems using cheap or < class4 sd cards.
m.klinge said:
When i read those lines i knew that this post would be worth reading
It was a really nice n00b guide, though ive done some WiMo flashing so some of the terms sounded familliar i certanly learned a thing or two
I would say it should be stickied and put on the wiki - oh and perhaps list it in alphabetic order, it would make it more usefull as a "I dont understand this term so ill just look it up"-thread...
Perhaps you can get a mod to give you post #2 & #3
//M
Click to expand...
Click to collapse
lol... I'm glad you liked it.
And thanks for the tips. I'm gone for the weekend, but I'll alphabetize it when I get back. Not sure what I can do about getting it stickied but I'll look into the wiki on monday too.
can you add busybox
in the nandroid instructions it requires busybox but I didnt see an explanation for what busybox is. Thanks and this thread has already been very helpful for me
speaking of stickying this....
who is in charge of stickies? A lot of stickable topics aren't stickied and a lot of topics that should be unstickied are still stuck...
DMaverick50 said:
in the nandroid instructions it requires busybox but I didnt see an explanation for what busybox is. Thanks and this thread has already been very helpful for me
Click to expand...
Click to collapse
Hey sorry for the late reply... Been pretty busy since Friday.
I'll try and add this to the first post shortly. I may have to remove some of the history lesson if I can't get a mod to give me the second/third post.
BusyBox - This is a single executable utility that contains many common Linux commands, instead of having an individual executable for each command. As far as I know this is built into all of the JF releases, as well as Dude's. It is also usable in the JF recovery console by hitting alt-x. To use busybox, just type "busybox" in front of the command you want to use (i.e. #busybox ls -L --to get a list of your directory).
AbsoluteDesignz said:
speaking of stickying this....
who is in charge of stickies? A lot of stickable topics aren't stickied and a lot of topics that should be unstickied are still stuck...
Click to expand...
Click to collapse
If you figure this out, let me know. I haven't tried to PM a mod or anything but I'd still be curious to know what the magic requirements are.
This will definitely help a lot of newcomers. Thanks for taking the time to make it.
Way to get stickied! Now I can stop copying pasting updates worrying I might not be able to find the post...
skri11a:
BusyBox - This is a single executable utility that contains many common Linux commands, instead of having an individual executable for each command. As far as I know this is built into all of the JF releases, as well as Dude's. It is also usable in the JF recovery console by hitting alt-x. To use busybox, just type "busybox" in front of the command you want to use (i.e. #busybox ls -L --to get a list of your directory).
Click to expand...
Click to collapse
Wouldn't "Unix utilities" be more correct than "Linux commands"?
And saying Android is "like windows mobile" is blasphemy! You can't compare Unix to Micro$oft Windoze (Yes, that's a very sophisticated and mature way to express my hatred of the OS )! >:|
Anyway, it's good that you wrote this, theres probably a lot around here not having a clue about how things work in the world of unix
I'm thinking about creating an application ( based on GScript ) that allows Rom developers to add the ability for rom developers to run shell scripts after the actual rom is flashed and to allow the user to run some rom-specific scripts.
I don't know if there is any need for this by any of the devs, but i have seen TwistedUmbrella used GScript Lite to add some scripts to his build, so that people don't have to ask the same question on how-to run the scripts ( and commands ) over and over.
Although GScript can be easily used for it I think that a special project could offer much more then this and the actual output can be a lot user friendly when its less generic ( i have done the same for the LucidREM script application which can be found in the market ).
And maybe the ability to run some scripts when the actual rom is started the first time after flashing etc.
If you think this could be useful in rom deployment or you have ideas/feature requests etc please drop a post so i know if its worth the work.
like UC
Kinda like UC for windows mobile (I said kinda)? I suppose it could have its uses. First thing that comes to mind is automatic restoration of sms, wep settings, etc.. after a wipe. One thing I like about the g1 is it so easy to build and customize your own builds in comparison to winmo (from a development standpoint). Well, depending on how you look at it I guess.
Curiously, If a function or program like this existed already, what uses would you get from it.
Edit)
I suppose it could be useful afterall. I drew a blank when I initially read your post because everything I run from a script or terminal for that matter is because I'm not behind a computer. If I'm gonna modify something it can be implemented in the update.zip before flash ect.. but if I'm flashing a new rom and I want the dalvikvm updated, louder sound mod, Odex optimized, etc to be done from the first boot I guess it'd be cool. But usuall i'd implement it in an update.zip. I donno I don't think I'm thinkin creatively enough about its uses.
We could create an easy way to backup/restore sms mms bookmarks etc, which can be started before updating and which will run to restore when the image is flashed.
Automatically create the apps2sd settings etc after a flash.
Or even create "smaller"-distributions which asks if the user wants to download extra applications after reflashing...
We could even incorporate google source projects so that users can look for and report issues from within the app for the given distribution.
An easy way to bring out small updates without users having to reflash or have to do manual stuff
Just shooting out some ideas....
I love this idea, I'm a huge supporter for GScript so this only seems natural. Since I use gscript after wipes/loading custom roms ANYWAY it'd be awesome if the process was automated. Chances are people are going to want to restore previous settings and info when they load new roms. I hope more Rom devs see this. So mildly bumping for notice.
Eventually user support will be deciding for developers to use it or not...
I will have a test application finished in a few days.
I will post the first screenshots tomorrow if i will find some time...
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Huh. I've been wondering if this was possible. I haven't tried this yet but if it works, nicely done! I think that this would be a huge improvement and addition to the themeporter programs that are out there. There is a high demand for this in that area and in the area of HDPI>MDPI/MDPI>HDPI conversion. I'm certainly bookmarking this!
Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.
Daneshm90 said:
Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.
Click to expand...
Click to collapse
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.
erasmux said:
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.
Click to expand...
Click to collapse
Hmm k i'll spend more time with it, perhaps the resizing program im using causes mishaps. Currently when i resize it completely messes stuff up even though the resolution corresponds to a mdpi device.
I'll do the good ol' trial/error n let u know. Thanks for the (proof of concept)
Edit :
Ok so upon using ur code for transferring images of diff sizes u can obviously tell whts up
So one improvement im thinking off, is if the images differ in size, it could draw the border and eliminate anything outside it. Ugh gotta brush up on my java though :S
bump
10 del al char har
bump
I tested it out and it works great! Thanks!
I really hope someone takes this idea and runs with it! If I knew how to code, I would certainly look into this. Maybe I can get one of the Vibrant Devs to look at this....
erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Can U just tell how to use this code for bulk images?????
pratyush.creed said:
Can U just tell how to use this code for bulk images?????
Click to expand...
Click to collapse
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....
erasmux said:
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....
Click to expand...
Click to collapse
Gr8 work...u made themin a kid's job
Sent from my GT-S5670 using XDA Premium App
???
does the original still work cause im on windows 7 64 bit and i was able to copy the changes to original but not it makes no changes at all, so the original file doesnt get the changes...
please help!!
Hi.
Before I start with my question, just a little background. I work in a user guide development firm, and mainly work on Galaxy devices.
One of the most time-consuming process in my work is to match all UI strings (app names, menu text, labels, etc) of the actual device with the user guide.
This is currently being done with human power, with a staff looking at the user guide, check the device if this is correct, and annotate the draft PDF if the UI strings don't match.
If this was for just one language, it's doable. But with 40 or so languages (including Arabic, Cyrillic, Chinese), it definitely makes me want to puke.
This is a very tiring, eye-straining work that I'm trying to resolve, for everyone's sake.
I tried decompressing the Galaxy firmware myself, but the XML data is encoded into binary(for what reason I have no idea), and is not readable.
So now I'm turning to the masters and hope for any luck.
What I would like to know is ...
Hack the Galaxy firmware(md5), and extract UI strings for all language and save in spreadsheet or something, or
Mirror the device's screen on the desktop, copy the desired UI string, and paste it to a desktop application(e.g. Adobe Acrobat).
If the first option is possible, then I can utilize the data for some sort of automation, and would be the best.
If the second option is possible, then I would no longer have to type all kinds of foreign characters(this is also a very time-consuming work), and make some progress in timeline.
If all options are not possible, and there's absolutely no way of automating this process, then well... I guess I'll go see the eye doctor more often than now.
Any ideas or helps would be great.
Thank you.