Related
I am new to Android and am attempting to experiment a bit with my brand new sgs2. This is my 3rd Android phone. I have a basic understanding of the modifcations that can be done to the OS to make it more efficient, but don't quite understand all the little details. I have already done research, I just need someone to put it into laymans terms.
Deodexing
I understand that deodexing is an almost necessary part of any custom rom. I have found scripts that will deodex the firmware for me. I see that you can deodex the filesystem and 'framework' of the OS. What else can be deodex'ed? I see that a lot of roms boast FULLY deodex'ed. What does that entail? How would I use these scripts to make my stock rom 'fully' deodex'ed. Also, from the information I have read, deodexing makes the APK actually bigger AND run less efficient. This would actually slow the OS down wouldn't it? I guess my question is, what is the actual benefit of deodexing?
Rooting
From what I understand about this device. All we have to do is flash SU 3.0 and that will root the decvice. And the only way to flash SU 3.0 is with CWM. Is this accurate? I also understand that to get CWM on the phone we need to flash it in download mode, which essentially replaces the stock recovery option. Is all of this accurate? If so, can someone point me to a thread where it will give me the proper CWM and instructions of how to flash it? I have done this on my tab 10.1 so I assume it would be very similar.
Custom power menu
Now something like this is an actual customization of the OS. What I want to know is if the power menu is just simply modified to show the additional features (reboot, recovery...) or if a whole new image has to be created to replace the stock power menu. Also, would there be any way I could take a custom power menu from another rom and insert it into my own or would I have to have one made specifically for the device?
Zipping up a ROM
Last question I promise I have a buddy who knows nothing about electronics. He wants to have the benefits of a modded rom that is slightly faster but is terrified of digging into the device because he thinks he will brick it. I was thinking about helping him but the only thing I can think of is to mod my device and create a nandroid backup of my own device and then restore it on his. Thats all I would be capable of without some guideance. How hard would it be to take my own modded rom and make it into a flashable zip rather than me try to restore a huge nandroid?
I was thinking about posing these questions directly to one of my favorite dev's via PM, but they have a lot on their plates and I didn't want to bug them. I feel like everyone in this forum is more knowledgeable than I am and there would be plenty of people willing to lend some info. Anyways thanks in advance.
Deodexing - This is something I've never done before, so I'm not familiar with the details, but the basics are: Deodexing will cause a small penalty in startup and boot times, but it makes theming and modifications MUCH easier. Theming/modding odexed ROMs is a massive pain in the ass as I understand it.
Rooting - Multiple ways to do this, I suggest reading jivy26's FAQ.
Custom power menu - I think only small parts of the framework need modding here (SystemUI.apk maybe?), and these modded parts could be flashed in CWM. However it's not something I've done before, nor do I know how to do it. Android userland is still black voodoo magic to me. I'll stay in the bowels of the system thank you very much.
Making CWM-flashable zips - also not something I can easily provide advice on. There are tutorials floating around.
Risk of bricking - as long as you don't flash bootloaders it's next to impossible to hardbrick a Samsung android device.
So essentially if Im looking to have the snappiest Rom possible which retains all of the functions and visuals of TouchWiz (no themeing or modding necessary) I would want to actually AVOID deodexing my system?
So what does that leave me with to speed up my stock Rom? OC, ram tweaks, and zip aligning?
Sent from my SAMSUNG-SGH-I777 using XDA App
Note: more content is coming regularly, so check back regularly! Also, post your input so this thread does not become buried.
As an initiative to kickstart development for the Galaxy Player 4.0, I have decided to put up this guide to try and attract more users to rom development. This, although, does not mean you can willy-nilly post up a rom including one mod, or a quick tweak. Making a rom involves a lot more than that.
The Developer's Code:
1. Your rom MUST be unique from the other roms.
This means you have to have a careful, well thought out rom. It must have several things differing it from other roms, something that makes it stand out. The last thing we need are 200 "me too" roms cluttering up development. Takes Klin's rom and mine, for example. We both have ICS themes, we both have tweaked our roms for performance, but they are both completely unique. Why? Because we didn't copy one another. We saw what the other had, and left it alone. I have an ICS theme, he has an ICS theme, but they are based on completely different themes. The biggest boo-boo in rom devving is copying someone else's rom/features/work. You will get kicked out unbelievably fast if you DO NOT follow this rule. To reiterate, the last thing we need is 200 identical roms. Make sure yours is unique from the others, and has a defining feature.
2. You must be willing to provide regular, consistent updates.
Maintaining a rom can be a full time job. You have bugs to deal with, features to add, and hours of work in which you only accomplish a small amount of work, due to some catastrophic failure. Last night it took me over 3 hours to fix a battery icon issue. Why? because I had almost space left in which to apply my fix, and if I did even one step wrong I had to reflash to correct the issue.
You should NOT release your rom once, and never look at it again. You should be willing to update it at least twice a month, if not sooner. I update mine several times a week, but that's because I have a lot of free time. Your mileage may vary, but try to hit for that mark. Too long wihtout an update and users will get bored/tired of your rom without anything new to spice things up.
3. You must be willing to provide helpful, friendly support.
At times, monitoring your thread can be frustrating. you may have someone complaining about an issue that was fixed several releases back, or someone who wants a new feature and keeps bugging you about it. It can be frustrating at times, but make sure you calmly answer everyone's questions in a fair manner. It can be extremely frustrating for a rom user to post up a question, and have it answered days later because the dev was "too busy" to monitor their thread. This, if anything, is almost more important than rom updates. Users love devs who actually converse and answer them, so be friendly, and keep your thread going!
4. ALWAYS ALWAYS ALWAYS give someone the apppropriate credit for their work.
It is the bane of the dev's existence: spending days/weeks/months of xyz feature/theme/rom, and have someone come along and snatch their work from them without as much as a "thank you". First of all, it will get you banned faster than any other offense out there. Secondly, it is one of the largest insults you can give someone. Our community is one that is supposed to share work, and most people do that freely, but you MUST give credit where credit is due. It is best if you ask someone's permission before you use their work, especially if it is something major (a huge theme for example). But even if you don't (and you should), at the very least list their username and what they did in your rom SOMEWHERE in your description.
5.You do not know everything.
After creating a rom, many people feel that they know much more then the "average" community, and that they are always right when it pertains the their rom. This could not be more wrong. The best way to improve your rom, is to listen to xyz person who knows more about a certain area than you do, and attempt to learn from that person. Everyone is skilled in a different area, so if you listen to your community, and assume they know best, you can learn and accomplish a lot evry quickly.
6. Google is your friend.
Do not assume that dev's know everything, and that they pull these features out of their heads. When in doubt, go to google. Always. There is normally a guide, or someone with your issue to help you out. As usual, make sure you give that person credit if you use their work.
So, to sum it up, Make your rom unique, be dedicated to your work, be ready to handle unexpected situations, ALWAYS give someone appropriate credit, listen to your community, and google a lot!
Not intimidated yet? ready to bring your amazing idea to the limelight? head on down to the section below to get started!
The Easy Way to Dev: Odin flashable packages.
Most people don't want to edit their rom on their computer. As a matter of fact, you can create a killer rom without even touching a computer to mod it. Up until I started theming, I working on my rom 100% on my device. This is the most tried-and-true method out there, and the one most likely to create the least drama. All you have to do is Pull the /system partition from your Player, and create a tarfile out of ti.
Prerequisites:
Samsung Device (system partition location may change with device type. This should be the same for US/INTL players)
PC running Ubuntu/form of linux (ubuntu is recommended for beginners)
ADB installed (actually not needed, but speeds up the process) (look below in resources for a guide)
appx. 300mb free on /sdcard
about 1 GB free on the Linux box
1. Apply whatever mods you want too
2. Open up a terminal emulator
3. type this in: dd if=/dev/block/stl9 of=/sdcard/factoryfs.rfs bs=4096
4. wait for it to complete (may take up to 10 minutes)
5. You now have a file called factoryfs.rfs on your internal sdcard
6. Hook it up to a computer and activate usb storage
7. copy factoryfs.rfs to whatever directory you want (home is recommended for simplicity)
8. Open up a terminal
9. cd to the directory of your file (if you placed it in home skip this step)
10. Type in "tar -H ustar -c factoryfs.rfs >packagename.tar"
11. Now you have a odin-flashable rom!
ADB users, simply run adb shell and type in the first command, then adb pull the file to the computer.
If you want to save space for a file sharing website (eg. mediafire, which has an upload cap of 200mb), simply Zip the file using 7-zip (set on ultra). You may have to do this on a windows machine.
Now this is even easier! simply flash the stock image in the link below with all the essentials included, and you can apply all the mods you want without having to ever go through dsidxa kitchen! Klin even fixed busybox for you! this way you can easily start from stock and work your way up to more advanced hacks.
http://forum.xda-developers.com/showthread.php?p=27973753#post27973753
The Advanced Users Guide: CWM packages.
Maybe you want more flexibility. Maybe you need to deodex your rom to mod some stock files, or zipalign to speed things up. This guide is for you people who need the more advanced options. It is harder, and you have a greater chance of messing things up, but you get to completely control your rom, even easily edit it on the computer! This guide is for advanced users only, or someone who is willing to spend a lot of time on trial and error.
Prerequisites:
ADB installed (Extremely helpful, and may to required)
Samsung device
Ubuntu/linux box
A bit of caution
Patience
1. Install Dsidxa Kitchen
2. Put your factoryfs.rfs in the necessary folder
3. cd to the directory you installed the kitchen
4. Type "sudo su"
5. enter your password
6. Type "chmod +x menu"
7. run "./menu"
8. you are now in the main menu of the kitchen.
9. There are many options, choode the one that you need!
Note: stay away from installing busybox using the kitchen. It installs a bad version of busybox which can make rom development a big headache for you!
10. There is a working folder in the kithcne directory, in there mod all the files you need.
11. When you are done, head into option 99 (create rom)
12. Run the interactive option
13.When you get to the update-script type, type "y" to install the newer type, which is required to flash a cwm zip in the Galaxy Player.
14. If you want to flash your rom using stock recovery, sign it. Else, leave it alone.
15. You can keep the normal name, or change it to what you want. If you are going to be flashing using stock recovery, make sure it is named "update.zip"
That is it! If you want to create a odin package out of it, simply flash the cwm zip, then follow the instructions above!
I will be adding on to this guide as time goes on, so make sure you ask pertinent questions below!
Resources/Additional Guides:
Install ADB:
http://forum.xda-developers.com/showthread.php?p=11823740#post11823740
Install dsidxa kitchen:
http://forum.xda-developers.com/showthread.php?t=1303311
4.0 base (essentials installed, just apply your hacks and you are good to go! thanks klin):
http://forum.xda-developers.com/showthread.php?p=27973753#post27973753
Easy theming guide:
http://androidforums.com/optimus-m-...guide-theme-guide-noobs-adding-lots-more.html
APK multi-tool (needed to theme):
http://apkmultitool.com/?q=node/5
Recommended hosting sites:
www.mediafire.com
Good Rom practices:
1. If you retheme, include screenshots! people love screenshots.
2. Make a logo if you can, it makes it easy for people to support your rom by adding it into their signature.
3. If you mod, make sure you can easily explain it to someone if need be. Messy hacks are not good in the long run!
4. Focus evenly on all parts of your rom. Some people love speed, others love features. You can focus on one or the other but try and keep it balanced.
5. If you create a custom script/init,d script/documentable file make sure you include comments in your mod so people can try and fix it if need be!
6. Make sure all the bugs are ironed out before release. People love fast releases, but if it is really buggy they may switch to another rom.
7. if you have exhausted all other methods of fixing an issue, or cannot work on it a lot in the opcoming days/weeks, release a beta version stating the bugs clearly. That way while you are gone, more experienced people can help you iron out the bugs.
8.Make sure it is easy for the person to obtain your rom. If they have to download another utlity or click through 30 ads, they may just want to use another rom than go through the hassle. Worse, they may mess it up, forcing you to help them troubleshoot.
9. Make sure you update utilities on your rom as soon as an update becomes availible. That way you get the fewest bugs, and as I said before, users love updates!
10. Even if someone's issue seems isolated, at least spend some time with them figuring out what happened so they can fix it. You never know, it may be the harbinger of a HUGE outbreak of issues.
11. Base your rom on an intl version. There is a fortunate "bug" that klin discovered that allows US users to use any intl rom without their home button breaking. Of course, that has a lot of asterisks, but if you will look below, I have developed a fix for that issue, which allows anyone with a "broken" home button to use it with the problematic rom!
12. Practice good rom devving. If there is a major issue that could be a pain, don't take the easy way/fix out. That always comes back to bite you later, as I have figured out. I once had a corrupt journal on my system partition, and did not want to go through the hassle of recreating my rom on a clean partition. So, I simply added a flag to have /system mount as rw if there are any issues. Sure enough, about 3 days later, I started having some filesystem issues, and had to completely rebase, because I did not have any backups.
13. ALWAYS keep backups. Just do it. Not just one, either. Keep at least three days worth of backups, just in case there is an issue in backup 1 and two, but it not in no. 3. This would have been hugely helpful to me in many cases, but I didn't want to "waste" the space. Guess what I did a few days later: spent a nice evening with linux fully recreating my rom from scratch. Just do it.
Fix home button issues. (useful if you use a rom seperate than a flasher's region) (developed by me)
I have finally, after a bit of luck and some know-how, determined a fix for the home button issue! This will work on ALL roms, not just this one, and will probably work for the 5.0 as well. This also means you can fully wipe data if you want, and simply apply my fix.
1. Navigate to /dbdata/databases/com.android.providers.settings
2.Optionally copy to a computer (easier that way)
3.Open it up in a sqlite editor (if you are doing this on the device, copy it to /sdcard and and then copy it back
4.Navigate to the locale/first section (there should only be one string in there
5.It should look like en_US if you have a US player, or en_GB if you have a UK/intl player
6.Change the string to the language/locale you use (if you are INTL you can merely change it to xx_GB, where xx is your language. If you are US, just perform the same steps, but change the last part to US)
7. commit/save the file and copy it over the old one
8. Reboot, and your home button *should* be fixed!
NOTE: I have not personally tested this. It has a 99% change of working, but I have yet to completely verify it.
NOTE: after you replace the file, android may go a little haywire (wifi disconnects, forgets password, advanced reboot option unavailable, etc.). THIS IS OKAY. Simply reboot, and it will all be back. Do not change any settings after copying until it reboots, as it may possibly break the fix
NOTE: I cannot provide a downloadable file, as that file contains all of your system settings, and if you use mine, my settings will be applied, which could be pretty bad in some cases.
NOTE: this has no chance of bootlooping or bricking your device. At absolute worst, you have to set up a few settings/restore from a /dbdata backup. There is almost no risk involved.
Potential fixes for potential issues:
1.Bluetooth breaks. The main cause of this is if you install supercharger and nullify. Simply unullify and verify it is remove from build.prop, and you are good to go!
2. Home button breaks. (see above )
3. Root/busybox breaks. It's kinda messy, but if you absolutely HAVE to, simply reroot. That should fix it in a pinch. This is a classic case of keeping good backups. I have had to spend an entire afternoon redoing my entire rom because of my lack of recent backups. If you have the space, keep them. I have more than once managed to create a stopgap solution in my rom just to have some weird issue pop up again, and again. Just do it.
I LOVE you, man.!!
Hanthesolo,
Very good achievement, we all have to learn from your good sharing.
Congratulations man
rgds
I am really happy you guys like this! I will continue to add to it as time goes on, so expect even more content!
Sent from my EtherealPlayer.
New content up! also notice the link to the stock rom klin made so that you never need to go through a kitchen to get your rom started!
Has anyone used this yet? successes/failures? make sure you give me feedback so I can make this better!
Yet mre content up! Could this be possibly stickied? I know it's a little rough right now, but noone replies to this thread as there really is nothing to reply TO. I have worked hard on this and would hate to see this information go the way of the dead threads.
Thanks for this info man, making roms for my old evo and just stacking up on guides and any kind of reading material that I can utilize for my advantage. So, this will be helpful lol. I'll be checking back every so often on anything new added, but thanks again bro. Thanks given! Feel Encouraged!! lol
iAMsalm said:
Thanks for this info man, making roms for my old evo and just stacking up on guides and any kind of reading material that I can utilize for my advantage. So, this will be helpful lol. I'll be checking back every so often on anything new added, but thanks again bro. Thanks given! Feel Encouraged!! lol
Click to expand...
Click to collapse
Glad you enjoy it, this forum is the abandoned, dusty wasteland of xda, so I wrote this guide to (hopefully) stimulate development a bit.
hanthesolo said:
Glad you enjoy it, this forum is the abandoned, dusty wasteland of xda, so I wrote this guide to (hopefully) stimulate development a bit.
Click to expand...
Click to collapse
I know it definitely feels like that from time to time, but that's a byproduct of the nature of our devices. There's ridiculous money in selling someone a shiny new crippled phone with a horrific contract that will never get updated. You won't see a jawdropping ad on TV featuring a Galaxy Player because there's just no money in it. I'd love to have the T-Mobile girl holding my phone while wearing a pink leather riding suit(her, not me). That ain't happening.
I'm pleased and more than a little shocked that some new roms have come out in the past month thanks to this guide. I wanted a Android powered phone without the contract. I wanted an iPod Touch without all the bull**** that comes from being tied to Apple. Thanks to XDA my device fast, sexy as Hell, and does everything I want.
The only thing that makes me sad is that a year from now I probably won't be able to buy a Galaxy Player 4.0 v2 because there's just too much money to be made from contract only devices.
Thanks for this guide. It help me for begin android development.
GalaxySWifi4 said:
Thanks for this guide. It help me for begin android development.
Click to expand...
Click to collapse
I hope you have fun beginning development! It really is a lot of fun once you et past the basics.
Gswifi, I never replied to you, but your speech was so awesome, that I want to put it in the OP .
If you want me to update the OP with an equivalent for ROM compiling (I know that I had a hard time figuring out just WHERE the folders to go, so we need a good guide...), chime in your support please!
hanthesolo said:
If you want me to update the OP with an equivalent for ROM compiling (I know that I had a hard time figuring out just WHERE the folders to go, so we need a good guide...), chime in your support please!
Click to expand...
Click to collapse
@hanthesolo
do you have some knowledge about kernel compiling, so you could hel me?
hanthesolo said:
If you want me to update the OP with an equivalent for ROM compiling (I know that I had a hard time figuring out just WHERE the folders to go, so we need a good guide...), chime in your support please!
Click to expand...
Click to collapse
please do
I understand early nothing about this advanced stuff of making ROMs, even more about make Kernels XD. But I want to experiment some little things to learn by myself step at step. But... I cannot start... I'm in CM10.1 with Koala's Kernel and I can't make the factoryfs.rfs file doing this: dd if=/dev/block/stl9 of=/sdcard/factoryfs.rfs bs=4096 in Terminal Emulator because /dev/block/stl9 doesn't exists. With ADB I have the same error.
Is this due to this ROM is not stock or something like this? Or only I have to create this folder or change it by other...
---------- Post added at 02:55 AM ---------- Previous post was at 02:37 AM ----------
I'm trying to do this but without if=/dev/block/stl9. I don't know if I'm doing well...
How about some info on modifying or tweaking already compiled roms?
Say you want to remove some of the apps included with CoolDevXYZ's rom or modify some of the settings pre-install (e.g. build.prop tweaks, etc.). How do you tell the kernel these changes are intentional, not the result file corruption, infection or something?
Ok I am trying to build a Torch APK from git sources from Wayland_Ace. I went to repository and downloaded them as a zip. I've set up ADT and have Eclipse running. I chose to create a project with existing sources and chose the folder I extracted from the zip.
Now, I want to make some edits to this and I already know how and what I am going to, but I figured I would make sure the app would build before I made any changes and it won't. I get four "TORCH_STATE cannot be resolved or is not a field" errors and few warnings about some imports never being used.
I have a feeling this is because it's importing the settings from stock Android and not CM10.1. Can anyone help me fix this so I can build a Torch APK. I've Googled and fooled around with this for hours and have not had any success and am getting a bit frustrated.
admiralspeedy said:
Ok I am trying to build a Torch APK from git sources from Wayland_Ace. I went to repository and downloaded them as a zip. I've set up ADT and have Eclipse running. I chose to create a project with existing sources and chose the folder I extracted from the zip.
Now, I want to make some edits to this and I already know how and what I am going to, but I figured I would make sure the app would build before I made any changes and it won't. I get four "TORCH_STATE cannot be resolved or is not a field" errors and few warnings about some imports never being used.
I have a feeling this is because it's importing the settings from stock Android and not CM10.1. Can anyone help me fix this so I can build a Torch APK. I've Googled and fooled around with this for hours and have not had any success and am getting a bit frustrated.
Click to expand...
Click to collapse
How are you trying to build the apk? Through eclipse or through the android sdk?
fairct said:
How are you trying to build the apk? Through eclipse or through the android sdk?
Click to expand...
Click to collapse
Eclipse.
admiralspeedy said:
Eclipse.
Click to expand...
Click to collapse
I took a look at the source (CMs, not the one you pulled), and it is indeed because you don't have the CM SettingsProvider. It may sound foolish, and I'm not sure what will happen, but you could try commenting it out. I think that's just updating a system var so that things like the power widget can update appropriately. Worst case scenario you get a force-quit, or your LED won't turn off, forcing a battery pull
fairct said:
I took a look at the source (CMs, not the one you pulled), and it is indeed because you don't have the CM SettingsProvider. It may sound foolish, and I'm not sure what will happen, but you could try commenting it out. I think that's just updating a system var so that things like the power widget can update appropriately. Worst case scenario you get a force-quit, or your LED won't turn off, forcing a battery pull
Click to expand...
Click to collapse
I'm not going to do that, however your answer is extremely helpful now that I know it's caused by settings provider. Do you know how I could use a different settings provider in Eclipse? I could take the CM10.1 from the git of the ROM I'm using and somehow use it in Eclipse.
I really find it strange that I can only find a couple other people asking the same question as I. Do people not edit a single app from Cyanogenmod or some other ROM like AOKP without rebuilding the entire source? Upon doing some more Googling, it seems I need an Android.jar from Cyanogenmod.
Hoew I get this, I'm not sure.
admiralspeedy said:
I really find it strange that I can only find a couple other people asking the same question as I. Do people not edit a single app from Cyanogenmod or some other ROM like AOKP without rebuilding the entire source? Upon doing some more Googling, it seems I need an Android.jar from Cyanogenmod.
Hoew I get this, I'm not sure.
Click to expand...
Click to collapse
Well, I think they generally pull whatever APK they want, and then modify it to make it work. In some instances, that means changing other apks due to interdependency. Maybe someone who's familiar with building in eclipse could point you in a better direction...
I did it. I followed a guide to build a custom Android.jar from my phones framework.jar and Eclipse wouldn't build after because of it, so instead I only replaced the class files for settingprovider and my app had no errors after. I then saved the class files I edited, decompiled the classes.dex from the existing Torch APK and replaced the classes in it with my edited ones, recompiled that into a new classes.dex and put that in the Torch APK and it worked!
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
oxiroxt said:
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
Click to expand...
Click to collapse
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
synesthete said:
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
Click to expand...
Click to collapse
OMG Finally some light! THANK YOU, THANK YOU, THANK YOU for all the info. I didn't get much right now, I'll need to read through your post a few times before I get it all, haha. I'll be sure to check the links too. Thank you!
As you might know, palm rejection on non stock roms has not worked for a long time. The symptoms are that when you try to draw with the s-pen in apps like squid or OneNote, often what you draw gets immediately erased.
I went back to CM13.0, where it supposedly did work, and checked what the difference is. I got lucky, and found the right files. It seems that palm rejection was removed from the file InputReader.cpp in frameworks_native/tree/p/services/inputflinger.
I'm sure there was a very good reason for that removal, probably because this is not the right place to do it. I tried to see what would happen if I put it back. I compiled XenonHD with the change, and now my s-pen works great! I tried squid, one note, gboard handwriting and others, and all works. I think this change can probably be easily incorporated into all AOSP/LOS roms.
The files are at https://github.com/ghostwheel/frameworks_native/tree/p/services/inputflinger , and you need InputReader.cpp and InputReader.h
As I said, there is probably a better way to enable palm rejection, but this works for now.
Update Actually, it seems the change was introduced between 14.1 and 15.0 . Look here: https://github.com/LineageOS/android_frameworks_native/blob/cm-14.1/services/inputflinger/InputReader.cpp. But I can't find the particular change that
caused this. Maybe it didn't have a great reason?
help me how to implement this to a rom
Might be interested in trying this (assuming I just replace/modify some files, right?) I'm assuming its harder than that.
Can you please make detailed tutorial? Both Havoc and LineageOs android 10.0 have this problem.
You just need to take InputReader.cpp, InputReader.h and also InputDispatcher.cpp from the github above to the code, in frameworks_native/services/inputflinger/. The problem is that usually you don't have control of that dir. If you take control, it is easy.
ghostwheel said:
You just need to take InputReader.cpp, InputReader.h and also InputDispatcher.cpp from the github above to the code, in frameworks_native/services/inputflinger/. The problem is that usually you don't have control of that dir. If you take control, it is easy.
Click to expand...
Click to collapse
Im suspecting you can use something like ES File Explorer (yes I still use an older version I have saved in TB) to just copy those files into the directory?
Dave
I used to use ES file explorer...
All these are source files that need to be compiled together with the android dist.
It might be possible to just copy the result, maybe services.jar inside framework??? Not sure. The right way is to download a distribution, copy the files into the right place, and compile. XenonHD has nice instructions of how to do all that. Though, XenonHD already has all that built in, for exactly that reason....
Thanks a lot, I am really new to all the terms you are using. All I know is to download zip file and flash it with TWRP recovery installer. I can also get the files fro github. What I dont know is: How to modify rom zip file and recompile it back to flashable zip?
Due to this issue, I am keeping my Note 4 in stock android 6.0 unfortunately, this will be life saver for me if you can help anyhow,
Thanks a lot.