I've had a few interactions lately about git and how to make more advanced use of it for development pn Android. I thought it would be worth sharing some good links:
git users manual
- Canonical reference for git
a tutorial introduction to git
- A simple set of steps that has you create a small git repository and play with it. Highly recommended to try.
Everyday git
- Takes the tutorial idea a bit further by essentially watching a kernel maintainer's screen. Good to skim over to see basic thought processes.
Branching and merging with git
- A very thorough article about branches and merging. Recommended, but is long.
gitref.org
- An exploration of the various commands git uses with fantastic examples and summaries
The tutorial is good to get you started, the "Everyday git" is good to start to learn how to use some of the power of git. The branching and merging is really important, but hard, to really understand some of the great power of git.
One piece of git that I think is particularly important for anyone that wants to send pull requests to public repos or maintain repos that other people will use is the "rebase" function of git. Here's a good example of using it in a standard development work-flow:
git rebase example
Before pushing commits, it's generally nice to look at them objectively and to ask yourself: would someone that didn't participate in the development of these commits read the list and make sense of them? Ideally, the one line subjects (git log --online --no-merges) should make a clear progression of commits, grouped by function/module/topic and with clear descriptions and subjects.
It is said elsewhere in the links, but I'll say it too. Don't rebase commits that you have pulled from the git server. You should not rewrite published history, only the history that you have created locally and are ready to push upstream.
Related
I've been following threads on here for a few months, and now I think I want to try to learn more about how Android actually works. I'm familiar with IDEs and coding in general(not my strong point), so I think I could pick up some things pretty quickly. Where would you guys recommend I look for learning to code/tweak Android code*?
I kind of want to be able to say I'm running my own cooked up version of Android.
*please ignore this redundant word choice, please.
rougegoat,
There is a fork in the road right at your starting point, strangely enough. You could choose to study Android application development, or you could choose to look at ROM "development". They are almost worlds apart in both nomenclature, toolsets, and skills; and because of the breadth of skills that are needed in both domains, I have no doubt that there are people that are simultaneously geniuses in one of those areas of expertise, and a numb-skull in the other: that's how far apart they are.
The former is all about Java, Android API's, the "SDK", and an IDE such as Eclipse, and emulators and the device bridge; the latter has a distinct "Unix jock" nature to it: Android "NDK", (or CodeSourcery) toolchains, gcc, make, command-line and shell scripting, understanding dynamic linking and execution environments, and use of configuration management tools (git and repo).
When "code" comes up in the former, it's Java; in the latter, ANSI C (or any other native-compiler language, but C is most typical). In the latter case, if you are building source trees from public repositories, (say Cyanogen or AOSP) initially you won't spend any time at all with C - you'll be spending 95% of your time struggling with with the build environment(s) and trying to wrap your head around the mysteries of "git" and "repo" - and also deciphering Unix shell scripts (typically written in the "Bourne" or "Bash" shell dialect) when things go wrong or are poorly documented. And yes, they will go wrong; effectively diagnosing what happened when things go wrong requires solid Unix/Linux skills.
Your question as posed suggests that you are more interested in the OS/ROM side of things than App development; if that is the case I would suggest you:
-brush up or learn from scratch basic Unix/Linux skill sets (they map over to Android almost 1-to-1).
-If you are a Windows user, download VirtualBox, and create a VM with Ubuntu (8.0.4 or 10x); use developer.android.com as a reference for dependencies and setup. Make sure the virtual disk is plenty big: at least 30-40 Gb. Don't attempt to set up a native development enviroment in Windows/cygwin. ( Windows is a great place for the Android SDK and Android App development, but decidedly not for native code development for Android "ROMs"** ).
-Install both the CodeSourcery and the Android "NDK" (Native Development Kit) in your Linux VM, and try and build a smallish, but multi-file C source-code project that uses Makefiles using both of those toolchains. (Sounds easy, right? Wait till you try anything involving the standard I/O library with the NDK).
-Get your simple project code to run correctly on a real phone device.
- Then, download and build an HTC kernel from their (standalone) source tree - try and do it with both toolchains (CodeSourcery and Android NDK) - simply for the experience of setting up the environments correctly.
- Then, learn the basics of dealing with repo, download an Android source tree and compile it - using both toolchains (CodeSourcery and Android NDK)
- After succeeding with the above, try pulling code from someone else's "git" repository and merging it into an Android build tree - and getting it to build correctly.
The above looks like a pretty short list - but it represents many, many hours of effort. Good luck.
bftb0
** There might be folks that take issue with that statement about ROM-building and Windows. They might tell you, "just download so-and-so's kitchen, and start building ROMs", it works fine under Windows." There's nothing wrong with that, especially because it can be satisfying seeing something of your creation actually running on a phone in a short period of time - but you probably won't learn very much, and when things go wrong, you'll be stumped about how to go about fixing things. The difference between a "chef" and a "developer" is that the former merely assembles together pre-built executable programs and libraries - whereas the latter understands not only how to go about building those things when the sources are available, but also has the opportunity to change them.
Lucky for me that I'm a Slackware guy. I'd much rather learn the system then just have a pretty GUI that does it all for me. That's half the fun of it.
Thanks for the advice, I'll have to try that whole bit out and see where it gets me. A weekend project awaits!
Introduction
As you all may or may not know by now, one of the biggest things that I believe in is a completely open source community, and as I delv deeper into the world of android, I am discovering how a lack of centralized data is causing a lot of headaches and time to be wasted.
Problem
In the past I have worked a lot on the kernel, and building mods for the nook table (trying to get kexec working) with some failure and some successes, however the one thing that I noted more and more was how much people repeated the same process. One thing I started to do when it was just Nemith Indirect and myself, was keep a Guide post, so that every one had access to the information. However as the community grows, I am unable to keep up with all that is happening.
Solution
In order to remedy this I (along with dj_segfault) have created the website nooktabletdev.org in hopes that people will contribute to it. The premiss is that by allowing others to read your guides, you will aid in the creation of future roms and such on other devices, and this one.
Information and Features
What to post:
Guides (extencive from building a kernel module to what repo to sync for CM7)
Compiled modules
Kernel configs
In the future I plan on adding:
File hosting capabilities, and linking along with change logs for Nook Tablet Roms
Git repos for community development
What should not be posted:
Anything that is not useful or pertaining to the Nook Tablet
EXPLOIT Explanations (trying to stay away from letting TI or BN patching)
Questions (Thats what these forums are for)
FAQs:
Why not use the XDA Wiki?
This wiki is used more for common knowledge and facts pertaining to hardware and current events on a device. nooktabletdev.org plans to be the overwhelming easy to search data base that will contain all of the knowledge on there plus more.
I found this awesome article on <insert topic>, can I copy it there?
Should be no problem but check with the copywrite rules of the source, and always make sure to source it so that it may be referenced against.
I want to help with the wiki!!!
Register on the wiki, and you can immediately add data (although it will be monitored closely).
If you wish to become a mod or be an admin please PM me or dj_segfault
I want to add something but I'm not sure if its useful?
PM, or hop on irc, and we can help you find out its usefulness. If all else fails just post it. We can always delete it later. MAKE SURE TO SEARCH BEFORE POSING TO AVOID DUPLICATES.
Information:
http://www.mediawiki.org/wiki/Help:Contents
Reserved for Future Use
AOSPA PARANOID ANDROID GOES OPEN SOURCE ON GIT
To all developers and maintainers out there,
we took our time to get a stable hands-free build-box ready, sorry you had to wait for so long but we had alot of work to do and we did not want to release something that is half-baked.
AOSPA is a new project for us, as you know, we started by basing on Cyanogenmod. This one is based 100% on AOSP. AOSPA is meant to be a stock oriented, lean ROM that delivers essential ROM-scene tweaks while retaining the elegance and ease of the original. We do not invest much time kanging other ROMs or teams, our primary focus is and will remain invention.
WHAT TO DO
As a developer you will need a couple of links to get up to speed.
If you just want to build, you find our Github here: http://github.com/paranoidandroid/
Kick it off by executing: repo init -u [email protected]aranoidAndroid/manifest.git-b jellybean
The only way to build PA is by using . rom-build.sh [devicename]
Hands off 'make' please. If everything works as expected it should ask for and fetch vendor files automatically.
If you would like to participate and help us, our Gerrit is here: http://review.paranoid-rom.com/
Legacy devices must supply their own trees and blobs. We do not accept any compromises to AOSP, please keep hacks out of it and overlay them properly.
Maintainers can freely take this project and release where ever they want. If you use our name, please make sure you stay true to our vision. Do not clutter this ROM with everything-everyone-ever-asked-for.
If you like to base your project on PA, no problem. Just treat the base with respect.
Kangers can take whatever they want, blow yourselves out.
NEW POLICIES REGARDING PA-PREFS
We unstamped the app and it may be used in any ROM. We do this under one condition. Do not mix it with DPI nonsense, ever! Do not merge it with AOKP's DPI changer, Dual-Panel Stuff, anything "true-tablet" related. If you do that we will pull it out of your project.
We do not wish to be the target of Googles retribution, and they take app-breaking VERY serious and could end any ROM if they wanted. Hybrid engine is safe as milk and will not break one single app in the entire Play market. But if you get our source wrong or mix it with conflicting code, you will - using our name and reputation. Please treat it respectful and give your users a decent experience!
Click to expand...
Click to collapse
Links:
https://plus.google.com/107979589566958860409/posts
https://github.com/paranoidandroid/
https://play.google.com/store/apps/details?id=com.paranoid.preferences.pro
http://www.paranoid-rom.com/forum/g...ut-how-to-compile-paranoidandroid-from-sauces
This should be fun to play with
私のEVO 3Dから送信される。
Hi all,
Is there a specific way to hunt down commits for feature sets in the source of ROMs on github? As a simple example, let's say someone was searching my ROM for how to enable AppOps in AOSP. They would eventually find this commit:
https://github.com/nowsci/platform_...mmit/a766afc88ebed960c2027d3d1539ff9a38be4115
However, many feature additions require changes across many repositories for Android. Let's say I want to find the Expanded Volume Control code for Cyanogenmod. The only way I can think to do this is to clone every single Cyanogenmod repository, print out the git log, and comb through for every mention of "volume" until I find the right commits.
How do other ROM developers shortcut this?
I ask for my own education, and because I think a central repository of "features" that links all the commits and provides the merge commands for AOSP might be a handy thing to start creating in the community (unless there is already a better way).
Thanks!
Gerrit is kinda a pain when it comes to searching but I finally played with Gerrit search syntax and came up with a couple of searches
find everything for cm13 merged in the past 30 days
https://review.cyanogenmod.org/#/q/...-project:^.*device.*+-translation+-age:30days
same but for cm14.x
https://review.cyanogenmod.org/#/q/...-project:^.*device.*+-translation+-age:30days
if you have a login for CyanogenMod gerrit you can save these as menu items for quick clicking
when logged into the gerrit instance go to your account's preferences and save menu items for
cm 13.0
#/q/status:merged+branch:cm-13.0+-project:^.*kernel.*+-project:^.*device.*+-translation+-age:30days
for cm14.x
#/q/status:merged+-branch:cm-13.0+-project:^.*kernel.*+-project:^.*device.*+-translation+-age:30days
now let's walk through the search flags used
this could be entered in the search box on review.cyanogenmod.org
status:merged -branch:cm-13.0 -project:^.*kernel.* -project:^.*device.* -translation -age:30days
let's look at our CM-14.x example since it makes the cm13.0 one make sense as well
status:merged to look for a merged commits
everything else had to be exclusions to get to what we want to see. the age: flag only looks for stuff before a certain date and a minus sign excludes so we'd have to use -age:#days/weeks,etc to show stuff in the past # timeframe
-age:30days
Since we're looking at the past 30 days, most commits (as of this writing) are on the Nougat/cm-14.0 branches and a little stuff on the cm-13.0 branch. So with our 30 day window, any merges NOT cm-13.0 branch are probably gonna be cm-14.x branches. If you can see, when cm-15 comes all you need to do is play with this part.
-branch:cm-13.0
I don't care about everyone's devices. I just want to see plain old CyanogenMod commits so I'll exclude the device and kernel projects. I used regular expressions to exclude any projects with either kernel or device somewhere in the project name. the carat symbol ^ enables regular expressions in Gerrit Search and the rest is regex syntax per Gerrit's documentation.
-project:^.*kernel.*
-project:^.*device.*
I also don't want to see any translation updates so I'll just put in a general exclusion on those
-translation.
I just wanted to write something up for myself. Might as well pass it along.
With these bits and pieces I could probably filter it down a little more but this is the guts of what I need to do so.
edit- refined it a little more
status:merged -branch:cm-13.0 -project:^.*kernel.* -project:^.*device.* -project:^.*hardware.* -project:^.*hudson.* -translation -age:30days