Hey, I've been using this ROM for the past month or so and it's been running great.
Anyways, I'm actually just starting to learn to develop Android ROMs (I'm a good programmer in general, but have virtually no knowledge of Android development) and was going to start to learn by messing around with the source of this ROM. However, before I start making builds and flashing them on my phone, I was wondering what is the best way to modify it so it will always start in airplane mode?
As I'll probably be backing up my daily, flashing my test builds, then restoring my original setup when done, I don't want to receive any calls or texts on the dev ROM. If I did, they would be saved on the temporary one which would get destroyed when I restore my original. Would the best way be turning on airplane mode in the init scripts, or do the radios start up before them? Pretty much if someone sent me a text while flashing the dev ROM, I want to make sure it isn't possible to receive it until I restore my original copy.
Oh, and I know it would be easy to just cripple the radios, but I would prefer it if I could turn on the radios if I wanted (like auto-airplane mode).
Thanks.
Mobster is correct, the option is in SettingsProvider. In the Source you will find it in “framworks/base/packages/SettingsProvider/res/values/defaults.xml” line number 22.
With that said Ill try to explain something I wish I had understood when I started making changes in the code no matter how small. Instead of changing the value in the code for the apk its best to use the overlay directory located in the Device Files.
https://github.com/HTCCM10/android_device_htc_shootervm
You would map out the directory in the overlay with a copy of the defaults.xml with the edit and it will be added to the build as the Rom is being compiled. We actually have a defaults.xml for SettingsProvider already set up. Kind of imagine most Roms would, plenty of reason wanting to change at least one those default. You would just need to set up the path for whatever XML you would like to add it in the directory. What I usually do is copy the original file into the end of the path set in the overlay and then delete everything else I don't intend on changing. Below is one example but if you look around the overlay you will see many more.
https://github.com/HTCCM10/android_...ages/SettingsProvider/res/values/defaults.xml
You could probably copy the air-plane mode line from the defaults.xml from the SettingsProvider XML in the frameworks and just add it into the defaults.xml already in the overlay.
Now the reason for making the change in the overlay and not the app is what I wish I understood when I first went ahead off on my own and started making changes. Whenever the source is updated or you do a repo sync to update the source you wont need to worry so much about busting repo sync or CM updating the the app. The quick explanation is that when you sync it pulls in changes or downloads the code following what is ironically confusing in this example but a default.xml. Below is the default.xml for Angry Bean.
https://github.com/HTCCM10/android/blob/cm-10.1/default.xml
What the default.xml for the most part does is when you repo sync or download the source it tells git what packages to download and then from ware on Github it should find each package. If you give it a look over you will see for example,
<project path="packages/apps/Calculator" name="CyanogenMod/android_packages_apps_Calculator" />
In short when you sync the default.xml is like a guide saying that in the source for the Rom you have a directory located in "packages/apps/Calculator" and it should contain the code for CyanogenMods “android_packages_apps_Calculator” repository on Github. So every time you sync the code it will download or look for changes made in CyanogenMods “android_packages_apps_Calculator” repository and add them to your source. So if for example if you wanted to make a change to one of the calculator XML's and made the change in the "packages/apps/Calculator" directory you would essentially mess up repo sync. You would need to make a fork or essentially make your own copy of the app on Github for “android_packages_apps_Calculator” and commits for whatever changes you make. You would then also need to edit your copy of the Roms default.xml so it would point to your Calculator repository on Github and not CyanogenMods. Doing this though you will no longer receive any updates from CM made to the Calculator repository when you run repo sync and would need to periodically update the repository with CM. Is probably not a big deal if you only make a few changes but even then by centralizing the changes by using the Overlay in the device files you would not need to worry about or be bothered updating the app other then making one commit in the device files.
The reason I used the Calculator as an example instead of SettingsProvider is because SettingsProvider is part of the frameworks base which is already heavily modified but for example after making a fork or copy of the repository the line in your copy of the default.xml would need to be changed so looking back at the default.xml posted above you will notice that for the 'frameworks_base" instead of it pointing to CyanogenMod,
<project path="frameworks/base" name="CyanogenMod/android_frameworks_base" />
like in the Calculator example will find it instead points to the Angry Bean fork or copy of of the repository, not Cyanogenmod.
<project path="frameworks/base" name="HTCCM10/android_frameworks_base" />
Anyhow none of the above gets into the how to go about actually doing any of whats mentioned and as a programmer you may already know. Otherwise just in case, sorry if I did a bad job with the explanation I just remember when I first started and thought I figured things out went ahead and pretty much made my own fork and commits to almost every app. Also remember being pretty dam proud of myself after figuring it all out. That is until I received an email from G60 explaining the concept of upstream. Basically that I would now periodically need to run an update of the 30 some repositories I had forked if I ever wanted any changes made by CM in my code. Busted my bubble real quick, like supernova style. This is when I first learned the wonders of what can be done using the overlay in the device files and never actually needed to touch any of the forks I made. Most painful part was then needing to delete those forks as Github requires that you type the full name of each repository before it lets you delete it.