Eyup, posted this on modaco, but will spread the love here
http://opensource.dell.com/releases/streak/
as of now its empty,
but they do have the Aero source available to peek at.
http://opensource.dell.com/releases/aero/1.5/
I've had a look, seems complete enough to build, but there's no references to proprietary stuff, whether that means its not able to build, or they havent used any I don't know.
without having an aero to build it for it's above my current level of knowledge to say whether it would work or not
That is great to know..
Hope they release it soon.
awesome, they need to get this up NOW!
http://opensource.dell.com/releases/streak/1.12/
Related
possible ?
Yes. I'm an Evo owner and compiled 2.2 for myself. Just download the source code and you have to modify a vendor tree (located in devices folder). I chose the Passion which is the Nexus One. Modify the vendor tree and bam, you can compile. Took me a bunch of tries for my Evo though and not everything works.
i have absolutly no idea how id go about doing this...
and everything doesnt need to work lol...
that will come if we can get one to boot its a start
luckily the post above is correct, its worth mentioning that there probably isnt a vendor tree for the streak... also worth mentioning that the OS could compile and be pretty useful, but we REALLY would need a kernel source from Dell (which they will HAVE to release to comply with the GPL) because we need a kernel intended for 2.1/2.2 because it interfaces with the hardware differently... so this can be hacked in, but its not really feasible to rewrite the drivers from scratch... wait till the 2.1 update, and Dell's kernel source for it, and 2.2 will be community supported well before Dell ever releases THAT update.
whhaaaaa?
What you think the time scale will be? Doesnt sound good
I was hoping xda cooks would be all over this...I have an hd2 and would say the streak beats it hands down for web browsing.
Have to agree on this nobody seems bothered to get 2.x on it maybe cos its only out in the uk at the moment but plenty of devs are from the uk ,? maybe it'll get more interest when it comes out in the usa.
i thought paul from modoca had a streak? I know he is a busy guy building roms for nexus? and/or desire?
we need to drum up support somehowl
we need kernel source compatible with 2.2
unless Dell have used generic components and I can't see that then it's not going to be a simple thing to do...
seriously, damn not good
I seen that a guy from modaco managed to get a Q&A will the Streak UI team and when asked about being updated to 2.2...they said this;
I can say that the team is busy working on the next release of Streak, and while I can't give specifics of what's in the release, I can say that getting Streak current with similar Android devices is high on our list.
So I hope they dont bork it with 2.1 instead
Few people works on new custom rom for it.
Sent from my HTC Hero using XDA App
If they do its a quick 2. 2 port
once we have a 2. X kernel.
Sent from my Nexus One using Tapatalk
Im beginning to suspect a vanilla kernel may work, not that well maybe, but there's not that much different from the N1 and desire in the streak from what I can tell.
There the same except the internal sd and screen. And screen don't really matter as its same resolution. Could try the 2.2 kernel. Even if the internal sd doesn't work. Its to the same qual comm chipset
Sent from my Dell Streak using Tapatalk
the kernel Dell are using is the Surf..
thats in the git. certainly a good place to start!
http://android.git.kernel.org/?p=platform/vendor/qcom/surf.git;a=summary
lazy dell...
so if we make a vendor...
from the surf and compile 2.2 .....
https://www.codeaurora.org/xwiki/bin/QAEP/
Have a play with that...
if I get a chance later I may do, otherwise it'll be later on this week, I haven't looked too closely, but I'm presuming it would also have the new HW 3d driver in there..
i wish somebody would do something with the streak coz at the moment its a doorstop, cant unlock it for a phone, cant use a decent rom on it coz there is none what a waste of £340
https://www.codeaurora.org/xwiki/bin/QAEP/
This is interesting - wish I knew what the hell it mean't ha !
Seriously though guys , good luck with this
Looks like there are some dell drivers after all. There is a dell_musiclibrary.so,
wonder if that is created by their music player apk..
I really need someone who knows their way around android to guide us through this, I'm learning fast but it's never fast enough!
Sent from my Dell Streak
Not sure if we've had this response so far but I wanted to share it.
______
Dear Dave,
Thank you for your continuous interest on our product.
In particular, we''d like to recommend to use toolchain 2009q3 version. Our development team recommend this version.
(arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2)
Please send full details of your build error log.
Thank you.
Sincerely yours,
Oh, where to begin..
I believe that's the toolchain they recommend in their "instructions".. Regardless, we figured that out rather quickly.
The problem here is that what they released to us was not their production source code. It was some early development version of it, with a number of issues, the most prominent being it didn't even compile as provided.
The fact that we had to patch sound/soc/codecs/wm8994.c so that the phone wouldn't drop audio 5-10 seconds into every phone call is pretty much concrete proof that what we were given was development code, not production code.
I'm going to pass on the exact same message back, we'll see what happens.
Probably nothing.
at this point it's fairly pointless. we have been hastling them for almost a month now, and they've done nothing. despite all the issues with the code, our dev team has gotten their provided kernel source to boot and run with no issues, hence the overclocking kernels available. even if they did release the actual source now it's basically worthless. unless it's for a higher kernel version we can use for a froyo rom.
sonofskywalker3 said:
at this point it's fairly pointless. we have been hastling them for almost a month now, and they've done nothing. despite all the issues with the code, our dev team has gotten their provided kernel source to boot and run with no issues, hence the overclocking kernels available. even if they did release the actual source now it's basically worthless. unless it's for a higher kernel version we can use for a froyo rom.
Click to expand...
Click to collapse
Its not whether I its pointless or not, they need to be held accountable for uploading bad source which I believe is against the gpl. Funny how their build sh is configured for 2010 and they recommend 2009q3...
Sent from my SCH-I500 using XDA App
I agree, but is sending them a million emails that they mostly ignore really "holding them accountable"? I think not.
So ignoring them is the answer?
I think not.
Feedback is the most civil thing at this point. If its ignored, I'm sure more stern action can be taken, if the community as a whole decides to.
I just saw that people are arguing on different rom threads and saying oh yours is better since you made this first but I tweaked it. (I mean no disrepect in that comment.)
Point being here is a interesting thing I thought of just to see what anyone else thought of. We have four main froyo roms Tazz, Kaos, Sheds and Conaps.
If people are fighting over whos to choose I was thinking maybe the four of them should make a combined rom since everything they use to build them is a combined effort anyway. I just personally think it would be interesting to see what they all would contribute and it would be the best rom all around due to it has everyones input. Its nice how they all are unique by themselves but it would be awesome to have them all mashed together if that makes sense. It would be fast, stable, and could probably even be updated more due to whomever had more time would be able to work on it.
I am not posting this to make people mad or to say one rom is better than the other I just think it would be rather neat to have one huge awesome rom to choose from. I know it would probably never happen but its a interesting thought.
I do not mean any disrespect or harm in this post either. I just figured maybe it would cause less arguments.
I just wanted to share an idea I had. What do you all think? Negative or positive.
sounds cool they all do seem to work together enough, lending each other things and being really quite friendly to each other on their posts. to have them together on a test ROM would be cool but i think they all have their individual ideas that keep them just different enough to make everyone happy no matter what their style i'm using Nonsensikal 16.1 now but i'm about to switch to Tazz... i'm not sure Vanilla or Gingerbread... overall though lol yeah i think that would be a great idea!! sorry i rant >< xD!
labnjab said:
I just wanted to share an idea I had. What do you all think? Negative or positive.
Click to expand...
Click to collapse
Having things in public view surely makes "who did what first" a non-argument - because one merely needs to look at the commits to find out who did what when.
As a reminder, devs who work on AOSP ROMs are under a GPL obligation to release their sources.
Without a doubt though, asking that cooks/devs publicly document their trickery increases their workload (in addition to build & test, add some "documentation" tasks) - so, the trade off might be better documentation - but fewer ROM updates per developer.
It is possible that having more information available about methods which are Eris hardware specific might encourage more people to participate in ROM "porting" activities, e.g. hacking of backlights, notification delivery, gps/sensor, and "pre-built" library requirements.
It is my impression that devs have shared some of this informally in private communications/IRC, but you would be hard-pressed to find explanations or mini-tutorials on most of these topics here on XDA (Eris) forums. That makes it more challenging for any would-be "ROM porting developer" - because they must re-invent those same wheels from scratch, or go begging to devs that have worked through those issues before. The latter certainly won't happen if they view the devs as combative or secretive.
I would suggest that if you can gain any traction with the devs on this, the baseline ROM should be AOSP - that way the GPL disclosure requirements align well with the benefit of making information readily available. (Perhaps never in the form of tutorials, but at least in the form of public source code).
bftb0
labnjab said:
Its nice how they all are unique by themselves but it would be awesome to have them all mashed together if that makes sense.
Click to expand...
Click to collapse
Well a lot of people don't like Sense UI so... But I think it could be a good idea. It's just hard to have to download the latest and greatest version anytime a dev wants to make a change, and two could never change it at the same time unless they were like teamviewing or something.
Yes it is hard having to switch versions everytime they make improvements & I didnt mean the sense ui. I meant i hoped the sentence made sense. Meaning all the newer froyo non sense roms rolled into one. Sorry for any confusion.
Sent from my FroyoEris using Tapatalk
I think Tenzo and Tazz have slowed down some of their development until they can get some common problems worked out.
I'm curious about something. Are there any roms for the photon that's built from the ground up by the dev and not based on anyone else's work? I've noticed that most of the roms for the photon are in some way based off another devs work on another phone just with minor tweaks here and there. Joker seems to be the only dev I've noticed that has done most of his own work.
Sent from my MB855 using XDA
Looks like you missed the point
This all here is the Android community and everyone uses others work, when making roms.
Even Joker uses others work. ;-)
Do not say anything about something,if you know nothing. ;-)
Except for pure AOSP builds, ALL ROM's are based off of either CM or stock (ports fall under one of these two groups as well). Pure AOSP builds are very rare as the dev has to write a lot of the drivers, framework and such from scratch. This applies to all android devices.
Pure AOSP builds on devices without full sourcecode from the component manufacturers are considered so time consuming that most devs never even both. A perfect example is the Tegra2 development board. Even those that have purchased the dev board do not have access to all the sourcecode as there's a lot of proprietary code that does not fall under opensource. Short of somebody risking some serious legal issues by releasing proprietary code the code is never released. At last check, nobody has all the source code for the Tegra platform.
Another example is during a conversation with agraben at the android bbq the subject of sourcecode came up. Both he and I were a little pissed the handset manufacturers are using wrappers (closed source) to get things like cameras and the like to work. In some cases the released drivers (open source) are pretty much useless as most of the functions are handled by the wrapper. Think of it as soft-drivers (proprietary) vs hard-drivers (opensource).
There is also a lot that goes on behind the scenes. It's not uncommon for devs to share fixes and such with each other. Lets say I find a way to make the mopho print money (I wish this was true). Unless I'm a complete d*ck, I'd send other devs a PM/email and give the code to any devs that want it. The most I may ask for is a mention in the credits.
Lokifish Marz said:
Except for pure AOSP builds, ALL ROM's are based off of either CM or stock (ports fall under one of these two groups as well). Pure AOSP builds are very rare as the dev has to write a lot of the drivers, framework and such from scratch. This applies to all android devices.
Pure AOSP builds on devices without full sourcecode from the component manufacturers are considered so time consuming that most devs never even both. A perfect example is the Tegra2 development board. Even those that have purchased the dev board do not have access to all the sourcecode as there's a lot of proprietary code that does not fall under opensource. Short of somebody risking some serious legal issues by releasing proprietary code the code is never released. At last check, nobody has all the source code for the Tegra platform.
Another example is during a conversation with agraben at the android bbq the subject of sourcecode came up. Both he and I were a little pissed the handset manufacturers are using wrappers (closed source) to get things like cameras and the like to work. In some cases the released drivers (open source) are pretty much useless as most of the functions are handled by the wrapper. Think of it as soft-drivers (proprietary) vs hard-drivers (opensource).
There is also a lot that goes on behind the scenes. It's not uncommon for devs to share fixes and such with each other. Lets say I find a way to make the mopho print money (I wish this was true). Unless I'm a complete d*ck, I'd send other devs a PM/email and give the code to any devs that want it. The most I may ask for is a mention in the credits.
Click to expand...
Click to collapse
The manufacturers are looking to create a competitive advantage between themselves and their "competition" (re: HTC vs. Motorola) so they proprietarize and hope to win. Where they lack foresight is that those "competitors" are the least of their problems; external forces drive the competitive market and these include Apple, RIM and Nokia. Open sourcing more of their code would leave them with many benefits and a handful of weaknesses, but the benefits would far outweigh the losses. They may not want the community to see their sloppy code or quality untested code. When everyone's watching, the audience able to poke holes in your quality is magnitudes larger than your QA folks. I've had my fair share of holes poked, but that's the joy - live and learn.
OP, the entire Android platform is based off a combination of coders' work, from the home dev up to Linus Torvalds.
I'm thankful for what those who dev on here do, because it can be a grueling and unappreciated process; but when it works >= expectations, hallelujah!
Has anyone use this yet? It seems powerful sshd. However, it require installing digicontrol that does not list if it is gpl or what...not sure if that is trustable?
Dropbear does not work for me, I got sh: /usr/libsec/sftp-server. File not found whenever I connect to it...so I'm looking for another open source SSHD.
kobesabi said:
Has anyone use this yet? It seems powerful sshd. However, it require installing digicontrol that does not list if it is gpl or what...not sure if that is trustable?
Dropbear does not work for me, I got sh: /usr/libsec/sftp-server. File not found whenever I connect to it...so I'm looking for another open source SSHD.
Click to expand...
Click to collapse
You may check GPL and Apache 2.0 part of source code... dropbear is binary, all patches published. All other (like DigiControl) is wrapper. You may trust it not more than other close source programs on you phone. But it is much more then other fully closed application at market. Hope it will be useful, because version 0.2.x published with help of users.
I am unable to open it absolutely all components, but I hope that it will be real in future when the project would be mature.
It is alpha software!. There are still some problems with stability and some features not implemented. But it worked.
Author
Ezzzzh said:
You may trust it not more than other close source programs on you phone. But it is much more then other fully closed application at market. Hope it will be useful, because version 0.2.x published with help of users.
I am unable to open it absolutely all components, but I hope that it will be real in future when the project would be mature.
It is alpha software!. There are still some problems with stability and some features not implemented. But it worked.
Author
Click to expand...
Click to collapse
Thanks for making it freebie. You are right on less closed source than others. Reason I was nervous was because instead of 1 piece implementation, it was 2 piece where the 2nd piece was closed source. As a user, I wasn't sure why it was done that way when most others did it all in 1 implementation. I guess you just want to protect your hardwork and didn't want to give it away or get gobbled up as part the GPL license which is understandable. Anyway, I did tried it earlier, it worked on Vibrant CM9. It seems like a powerful tool but the gui seems to make it complex to understand at first. I'll keep using it for awhile and let you know how it goes.