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!
Related
Being an "open source Home Replacement app", I spent a couple of hours yesterday trying to find a public repository where I could get ADWLauncher's code.
Looking at its google projects page, it seems that the project is quite active, yet the latest source I could find is under the CyanogenMod github, with ongoing translations but with sources last updated 3 months ago... In AnderWeb's github things are even worse with last commit over a year ago...
Does anyone know of a public repository where i could get the project's latest source code?
Thanks!
Found it !
Hi florpor,
you can find ADW Launcher repository on GitHub.
As I'm a new user, I cannot post you the URL, so here is the info to find it :
on github, look at the "AnderWeb" user projects. It is the one named "android_packages_apps_Launcher".
However, the project seems to be stalled.
Have a nice chekout
I don't think there is any source for the new version. There were many contributors on that project, but it looks like they have all agreed to go proprietary all of a sudden. They haven't announced anything on their project page, so who knows what's going on.
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から送信される。
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.
Hi!
Some guys and me are working on Android now for long time. Most times we had clear different parts we where working on, so two guys working on kernels, one on adaption of Android, one was testing and keeping contact to the community.
Now, cloning a kernel and merging some changes on drivers is a simple thing. And even changing a file on android, putting it into a git or simply on an ftp is easy too...
Well, now things have changed. Android is getting more complex and kernel work is mostly done.So we do more and more work in Android with more and more people.
Ok, one would say, take a plain android by using repo sync. Add your vendor parts for kernel and android and add them as a separate git. Ready you are...
Unfortunately that may work if you build your own device, based on plain naked android and a well supported mainlined kernel... But reality is different and chinese reality is even different^2. Hacking andoid devices where you do not have access to the OEM gits, kernels, not even datasheets or schematics is a hell of work... and all of these OEMs just checked out the complete android, put it in their own git and modified 1000 parts 'n pieces of it.
This isn't only a problem of bandwidth to upload such a monster, but all your friends supporting you have to clone that monster again. And after a while a new android version comes and you have great mess:
You cannot find differences from your old version to the new google version as many files have been changed by the OEM.
But you cant just "repo upload" cause google or CM might not be very eager to get dumb chinese deep down below android changes in their repos.
How do you team up with others and sync your android changes? Is there a good tutorial that handles not only the way it should be, but covers all these real-life issues?
I'd really appreciate your tips
Astralix
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