Is this source meant to be compiled for devices other than non AOSP because I got device files and everything and so far its going well.
Droid RAZR XT912
Sent from my XT912 using xda app-developers app
Nvm. I need some file called init
Sent from my XT912 using xda app-developers app
From 11/19:
CM 10.1 Status Update
So we continue to work through the merger of 4.2 code and our CM enhancements. A branch in our github repos called mr1-staging has been created to facilitate the merger and is the target for core CM items (not features).
mr1-staging is not meant to be compile-able, its only purpose is to be a staging grounds for our core work. Chances are, it is useless for independent builders.
CM 10.0 (4.1.2) code is in jellybean-stable, if you are working on a bug-fix for the last stable release, patches should be submitted against that branch. If/when we do another 4.1.2 release (ie CM 10.0.x), it will originate from code in this branch.
Once staging is done in mr1-staging, we will push all that code to a 'CM10.1' branch, and eventually back to our primary 'jellybean' branch. This process is in place to make sure that we effectively move forward from CM 10.0 code, instead of starting over as was seen with the jump from Gingerbread to ICS. Patches from gerrit will be accepted towards CM 10.1, but for now, please have patience while we work through mr1-staging.
While the 4.2 updates are on a smaller scale, they do present some changes that will need to be considered and will effect our implementation of features. Just to name them briefly: Telephony Split, Multi-User, Quick Settings, and Lock-Screen Widgets. These items will be a strong focus when the initial CM10.1 branch is created.
On the feature front, David van Tonder (dvtonder) decided to make his weekend productive, and has already worked on the code for the majority of our MMS enhancements: Emoji support, sms split, gestures and templates, quick messaging. Notably MMS auto retrieve is not being forward ported as Google fixed that themselves. As stated above, patches will hit gerrit review after this staging process is completed.
As always, a timeline isn't and won't be available. We will continue to provide updates as we have them.
Click to expand...
Click to collapse
and 11/21:
Cry havoc and let slip the...
...developers of CM. Hmm, not quite the same oomph to it. Back on topic...
mr1-staging as it's manifested in github right now, is good to build. Theme Engine support is not yet enabled, so if you attempt to build, remove vendor/tmobile. Everything else is in working shape with regards to AOSP devices, so if any of you are waiting for a working tree to move on to har
dware support, you can start now.
A bunch of our repositories have already been merged into mr1. The usual CM externals are in place, the CM build scriptage is also in and working. Features are not incorporated wholesale, and will be applied as conflicts with 4.2 changes are resolved.
Those watching at home, you should be able to break out a Mako (unofficial) build at this time. Our frequent contributors have been given the green light to send patches for review as features are rebased, recoded, and uploaded.
*Nightlies will not be available immediately, as even though CM may be build-able we consider it incomplete at its current stage. When we are happy with the product, the flood gates will open.*
Happy Dev'ing and say thanks to your patient lady/man for putting up with you
Click to expand...
Click to collapse
Related
I have been looking for a good CM 7.1 based ROM and am having a hard time deciding on one. The main thing I am looking for is the advanced lock screen delay and timeout settings. I cannot tell if this is a difference between CM 7.1 and 7.0.3 or if it is just a setting that some ROMs have and some do not.
Can someone shed some light on this for me? Is there a way to add this functionality? (I care because work enforced a security lock on my phone for email access, but I don't want to have to type i tin EVERY time the screen goes off. iPhones and WinMobile don't. It seems to be a flaw in Android's ActiveSync).
Thanks in advance.
This feature is new in CM 7.1. However, other users have reported success using Delayed Lock + WidgetLocker apps from the market to effect the same functionality, though I am uncertain how well they play with the Exchange server's demands.
Alternately, if you really don't want this security lock feature at all then you can find versions of Email.apk that will just lie to the Exchange server about the phone's configuration. Then you can configure your lock settings however you like. Ah, the classic fallacy of a security model that trusts the client...
I actually like the security of the password. I just wish it behaved like ActiveSyns on every other type of device (Win Mobile, iphone, etc) and let you set a delay (defined by the system administrator) for when the device security locks, not every time the screen goes off.
I wish we had a good CM7.1 ROM. Oh Z, wherefore art thou?
Yeah, running a nightly (or a ROM that pulls from nightly) is currently the only practicable choice to get the feature.
I backported the feature's code to the CM 7.0.3 codebase and built a custom ROM for my own device. I wanted the feature but didn't want to run the unstable nightly on my primary phone. Well, "backport" isn't the correct term, because the feature was developed against 7.0.3 and was rebased to 7.1 for submission to the source repo. But you know what I mean (haha).
organophosphate said:
Yeah, running a nightly (or a ROM that pulls from nightly) is currently the only practicable choice to get the feature.
I backported the feature's code to the CM 7.0.3 codebase and built a custom ROM for my own device. I wanted the feature but didn't want to run the unstable nightly on my primary phone. Well, "backport" isn't the correct term, because the feature was developed against 7.0.3 and was rebased to 7.1 for submission to the source repo. But you know what I mean (haha).
Click to expand...
Click to collapse
Care to share?
rearview said:
Care to share?
Click to expand...
Click to collapse
You know, I realized after posting that I probably look like a jerk for not offering. I apologize. There are issues that seem to preclude this, however.
The target of the relatively minor code changes necessarily included one of the fundamental framework jars.
When I was developing the feature, I only compiled CM for the Droid Incredible. Didn't make sense to compile for platforms I can't use/test, especially given the next point.
It takes my machine 90+ minutes to compile a ROM for a platform.
I believe that if I gave you a flashable update.zip to replace the affected jars it would have a high probability of cacking your ROM and would result in bootloops. Not absolutely certain, but fairly concerned about the possibility. I believe you would have better luck running a nightly that people report as "relatively stable" in the forums (some nightlies are better than others).
When the feature was merged, I really thought CM 7.1 would be out soon. RC1 dropped a month *before* the new feature was merged. That sounds odd in retrospect, because most projects freeze feature additions before entering the RC phase of a release (ie. they accept bugfixes only).
I just assumed it was for an X10 since we were in the X10 forums. Since this phone isn't officially CM supported I'm at the mercy of ROM developers to make a nice CM7.1. There are a couple out there, and they all have issues. One is close, but the dev seems to have gone missing. I hope he returns soon.
Is modifying one jar file all that it would take? Which file? If I knew that I could possibly take the jar file from one of the CM7.1 ROMs for my device (which has issues) and put it into a 7.0.3 that works smoothly and be happy.
rearview said:
Is modifying one jar file all that it would take? Which file? If I knew that I could possibly take the jar file from one of the CM7.1 ROMs for my device (which has issues) and put it into a 7.0.3 that works smoothly and be happy.
Click to expand...
Click to collapse
I like your train of thought. Unfortunately, even if that were to work you would be unable to configure the feature, because the UI is in the CM Settings apk (ie. the apk that makes "CyanogenMod Settings" menu option appear in your Android settings). If you were to also grab the CM 7.1 settings APK and install it, then that would replace the old version. The CM 7.1 version has all sorts of changes, controls for other new features, and so forth; therefore, that would break much of your other functionality.
How conversant are you in software development? You may be able to join one of those CM 7-derived ROM projects for your platform. It should be relatively easy for someone with a CM dev environment configured for your platform to grab these patches via git cherry-pick and build a 7.0.3 "Gold Edition" with this feature added. Because it should be easy, you might be able to persuade one of those custom ROM developers to grab this feature and include it.
If you are interested, here are the links to my patchsets that were merged to implement the feature:
Framework Implementation
CM Settings UI
I believe the patches will merge "nearly cleanly" into a CM 7.0.3 derived branch. That is to say, if there are merge conflicts they will not be substantive and will merely involve wholesale cut/paste reordering of methods within the given class files rather than requiring a rewrite of any part of the actual implementation.
I know that this simple reordering is all I changed between my 7.0.3 development version and the 7.1-derived submission. Seems Steve Kondik did a little further rearrangement to accommodate other patches that had been accepted/merged while mine was pending. Same deal there: still should be relatively simple.
I'm not much of a developer, though I'm an IT guy with some unix background. I'll look at it.
I'm working on a JellyBean port of Cornerstone. It is currently building with CM10, but does not work very well at all. I'm not sure if this has to do with the resolution of my tablet, 1900x1200 TF700T, which I tried to account for, but may have screwed up. I could use some help on this, as I have very little time and not much experience with building Android from source. Specifically, any advice on toolchains/testing code without needing to do an entire build would be appreciated. What would be more appreciated is if I could get some help with the project itself to get it to a stable place, and perhaps to include a path for continuous updates with as new releases come out.
https://github.com/emil10001/cornerstone
My current build environment is an Ubuntu VM, just using the commandline. I write the code and try a build. It usually fails and I go in and fix the errors that it gives me. This process means that I spend about 1-10 minutes coding and 2 hours waiting for it to build and fail. At present, it's actually building just fine, but it isn't working very well.
I really like the idea of Cornerstone and would like to see it working on newer builds. I am also reaching out to the Cornerstone Google Group, but they have been fairly silent for months. https://groups.google.com/forum/?fromgroups=#!topic/cornerstone-dev/Gz345pbd-co
Thanks,
John
I did talk with them a while back and the did say they're working on updating the codebase to support jellybean.
I had a quick glance at your fork.
This way its really hard to test, you could better just fork frameworks/base from android and then modify the files instead of the copying the changed files.
That would make it easier to test, view what changed, etc.
You could also use gerrit.
mmm path/to/it will do a quick rebuild.
I've had the apps up on github.com/sgt7 but they haven't been updated since way too long, will update them when I find some time.
Sent from my GT-P1000
...
Thanks for the tips!
The reason that I am keeping them separate is mainly for sanity, I wanted to try to keep the cornerstone stuff outside the main android code so that I can keep the android codebase relatively up-to-date, and also very obvious about what's a part of cornerstone for anyone that wants to grab the source from me. I'm also wondering if it's possible to pull part of this, say frameworks/base, into Eclipse (without it taking a day and a half to build the workspace).
Also, with gerrit, I wanted to keep this separate from the CyanogenMod stuff, mainly due to the comments that Dianne Hackborn made on G+ to Steve Kondik. I have a feeling that that's what killed the project.
I'd also really like to see how this works on a 1200x800 device, since that's what Cornerstone was originally designed for. I'm thinking that I screwed up the data in the xml resources, and that that's a big reason as to why it looks so funky on my device.
emil10001 said:
Thanks for the tips!
The reason that I am keeping them separate is mainly for sanity, I wanted to try to keep the cornerstone stuff outside the main android code so that I can keep the android codebase relatively up-to-date, and also very obvious about what's a part of cornerstone for anyone that wants to grab the source from me. I'm also wondering if it's possible to pull part of this, say frameworks/base, into Eclipse (without it taking a day and a half to build the workspace).
Also, with gerrit, I wanted to keep this separate from the CyanogenMod stuff, mainly due to the comments that Dianne Hackborn made on G+ to Steve Kondik. I have a feeling that that's what killed the project.
I'd also really like to see how this works on a 1200x800 device, since that's what Cornerstone was originally designed for. I'm thinking that I screwed up the data in the xml resources, and that that's a big reason as to why it looks so funky on my device.
Click to expand...
Click to collapse
Just checkout a new branch with the modified code, that's what version control is for.
Also, i believe it should be fine now if there is some sort of a whitelist implementation, and only few apps are supported by it. (*le Samsung Mutli Window)
cdesai said:
Just checkout a new branch with the modified code, that's what version control is for.
Also, i believe it should be fine now if there is some sort of a whitelist implementation, and only few apps are supported by it. (*le Samsung Mutli Window)
Click to expand...
Click to collapse
What happens when you try to use an unsupported app anyway? I have Note 2 with the multiview hack and every app I've tried with it has worked, though I've never tried anything like say Angrybirds, just google voice and Trillian and stuff like that.
Is this still something that you are trying to work on? GOD I would love cornerstone on my tf700!!!
Need some help testing/coding ect? I would love to help, not an advanced dev but working on my android chops daily.
I am available to help with testing.
Am a rom developer.
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