Hey everyone, I'm looking for a developer who will be willing to help and teach me how to make a kernel! I would like to be able to add anything I want; meaning I'm looking for someone to teacher how to edit and add things to make it my own, not just teach me how to compile. I've never made anything deal with a source code, meaning I've never made an AOSP ROM nor kernel; I have made some touchwiz based ROMs, but that's a bit different. I would like to start by making something for the nexus 7 (WiFi only) then moving my way to the GsIII (d2spr). I'm currently using opensuse 12.3 KDE 64-bit, on its own HDD. Please, if anyone could help me and teach me, it would be greatly greatly appreciated!!!
What hourly rate are you willing to pay? LOL
What I would recommend you do is to start simply by:
a) installing the current NDK
b) downloading a complete stock kernel build tree as a tarball (.tgz)
c) setting up a build environment and successfully build the kernel
d) unpack an existing boot image, stuff your kernel in there, & re-pack it
e) boot it on your device. Does it run? Congrats! You are a kernel-builder!
The reason that I suggest this outline plan above is that it initially avoids learning git & associated tools until after seeing something you've built running on the device; that's a confidence-booster. That's the good news.
The bad news is that becoming a *good* kernel dev from scratch means that you simultaneously are learning kernel coding conventions, build tree structuring, and kernel APIs *plus* achieving an excellent understanding of how git & gerrit work.
In addition to some amount of original source code mods authored by a kernel dev, they spend a fair amount of time integrating patch sets (commits) coming from unrelated kernel projects (e.g. Linux kernel mainline or kernel mods from unrelated devices). Learning simple operations (commits) in git is easy enough, but understanding branch creation & multi-way merge strategies in the face of cherry-picks coming from arbitrary places is a bit of a mind bender the first time through it.
And there is the issue of compliance with the GPL. As soon as you decide to make public your work, you have an obligation to publish your sources.
There is at least one way to do this simply: don't worry about git/gerrit/github at all - use whatever source code control system you want, including none at all. When you are ready to publish, you publish a patch kit that transforms a specific commit on some other developer's (or google!) tree to your tree. That should satisfy the GPL.
Another thing to consider is to build these skills in an incremental fashion: if you have in mind a very specific kernel modification of original authorship as a first project, why not consider submitting your kernel patches as pull requests to an existing developer's kernel tree? If your patch/mod rocks, other devs will incorporate it - and probably be much more willing to answer twisty questions from you. You scratch their back, they scratch yours.
The point of the above two strategies is that they allow you to build skills incrementally rather than needing to know everything before you can begin doing anything. Don't try to learn it all simultaneously.
cheers
bftb0 said:
What hourly rate are you willing to pay? LOL
What I would recommend you do is to start simply by:
a) installing the current NDK
b) downloading a complete stock kernel build tree as a tarball (.tgz)
c) setting up a build environment and successfully build the kernel
d) unpack an existing boot image, stuff your kernel in there, & re-pack it
e) boot it on your device. Does it run? Congrats! You are a kernel-builder!
The reason that I suggest this outline plan above is that it initially avoids learning git & associated tools until after seeing something you've built running on the device; that's a confidence-booster. That's the good news.
The bad news is that becoming a *good* kernel dev from scratch means that you simultaneously are learning kernel coding conventions, build tree structuring, and kernel APIs *plus* achieving an excellent understanding of how git & gerrit work.
In addition to some amount of original source code mods authored by a kernel dev, they spend a fair amount of time integrating patch sets (commits) coming from unrelated kernel projects (e.g. Linux kernel mainline or kernel mods from unrelated devices). Learning simple operations (commits) in git is easy enough, but understanding branch creation & multi-way merge strategies in the face of cherry-picks coming from arbitrary places is a bit of a mind bender the first time through it.
And there is the issue of compliance with the GPL. As soon as you decide to make public your work, you have an obligation to publish your sources.
There is at least one way to do this simply: don't worry about git/gerrit/github at all - use whatever source code control system you want, including none at all. When you are ready to publish, you publish a patch kit that transforms a specific commit on some other developer's (or google!) tree to your tree. That should satisfy the GPL.
Another thing to consider is to build these skills in an incremental fashion: if you have in mind a very specific kernel modification of original authorship as a first project, why not consider submitting your kernel patches as pull requests to an existing developer's kernel tree? If your patch/mod rocks, other devs will incorporate it - and probably be much more willing to answer twisty questions from you. You scratch their back, they scratch yours.
The point of the above two strategies is that they allow you to build skills incrementally rather than needing to know everything before you can begin doing anything. Don't try to learn it all simultaneously.
cheers
Click to expand...
Click to collapse
Wow, okay, thank you! I'll start with that. Honestly I like having someone just point me in the directions then me teach myself the rest! That is probably the best thing to do all around. I just have somethings:
1.) If I get lost somewhere and am not able to find answer for something anywhere; do you mind if I PM you?
2.) Almost everywhere I read---including from source.android.com---it say, use Ubuntu; why? Do I have to? Ubuntu doesn't support my graphics card---and isn't easy to set up, even when using things from other OSes or just other stuff someone made---which is kinda needed because of my monitors.
jamcar said:
2.) Almost everywhere I read---including from source.android.com---it say, use Ubuntu; why? Do I have to? Ubuntu doesn't support my graphics card---and isn't easy to set up, even when using things from other OSes or just other stuff someone made---which is kinda needed because of my monitors.
Click to expand...
Click to collapse
I've used Unix/Linux for quite a long time, and if there is one thing that seems to never change is package dependency differences from distro to distro. Getting them resolved is mandatory (when you are stopped out by them), but typically quite a distraction from whatever it is you are trying to accomplish.
By using Ubuntu you will be following the footsteps of many others in front of you (including Google developers), and that means that when you encounter a problem, it will be very likely that exact problem has already been encountered and resolved, and you can find the solutions on the internet. That may not be the case for some other arbitrary distro. So, why make your life more difficult?
As far as kernel development goes, you can do anything you want inside a VM, assuming your machine has enough ram (say 4+ GB) and disk space (say 100G free). So get VirtualBox and create an Ubuntu VM.
There are small downsides to using a VM, but for code-building they are just fine - their performance in doing kernel builds is probably 95% of native metal.
jamcar said:
1.) If I get lost somewhere and am not able to find answer for something anywhere; do you mind if I PM you?
Click to expand...
Click to collapse
I would never commit to something open-ended like that - esp. since you said you have never coded anything before. You are free to PM me though, so long as you understand that I am free to choose not to reply. Given those ground rules, it might be better for you to just post your questions in public (say stackoverflow.com) so more eyeballs will see what you are asking.
cheers and good luck - you've chosen a pretty steep mountain to climb.
Related
Ok, there is plenty of speculation on Android and can we run it on our HTC devices, etc. I have started this new thread dedicated to the MSM7K Kernel release, and what it will take to get this running on our phones.
I would like this thread to become a resource, rather than just general theorizing. For example: "I know we need driver X to run Y on HTC device Foo." What I am not looking for: "Android is so l33t, plez tell me how to run on my Zaurus kthx". The difference is that the first example is constructive, and adds to the discussion.
The signal to noise ratio on the Android gGroup is terrible, and mostly consists of wild theorizing, self-promotion, and arguing. I have a feeling it will improve, but for now I'd like to discuss this subject away from all the SuperKoolNewAndroidForum.com forums.
My Goals for this Thread:
Establish what is known to work, and what the kernel is sorely lacking.
a) I know we have booted Linux on HTC devices, has it been done on the most current devices? (please link to thread/proof)
b) What are the main major roadblocks preventing Linux from being run on more HTC devices? (Obscure hardware design, bricking phone)
Compile a list of needed and helpful software for loading Android: bootloaders, useful Linux tools, filesystem images
Provide continual updates with photos/logs as we (hopefully) make progress
My bet is that the current 'gPhone' in the videos is an HTC device not unlike yours or mine. [link to my blog] IMHO, the hype over 'When will the first gPhone be released' is irrelevant, as Google has been working closely with HTC and Qualcomm for a long time -- and the specs for Android are so low, Google clearly expects to be able to run Android on existing hardware, without needing new hardware technology.
Of course, the tools and software we need are all in existence already, someone at Google is doing a good job of keeping their mouth shut. Therefore this is not an impossible task, just difficult, but I know you xda-hackers like a challenge! So, Let's go!!
Charles
FYI: I am aware XDA was founded with the Xanadux project, so this should be the perfect place to hack us a gPhone. I've also browsed threads, read the Wiki, studied up on the Hermes Linux project -- but things seem to have died since Feb 07, I'm hoping this latest development with Android will spark interest again, and we will be able to run Linux on our current, most powerful devices. I could make educated guesses about the state of the Xanadux project, but I'd rather hear it from XDA devs themselves who are most familiar.
Reserved for knowledge & files
Ok, I'll start:
Android.com *Now redirects (finally) to OpenHandsetAlliance.com
Download Android SDK
Official Android Dev gGroup
Here's what I know:
Announcement of the Kernel on the ARM Linux Mailing List
GIT Repository
gGroup for MSM7K Kernel Issues
[credit to Brian Swetland, Linux Kernel Lead, Android Project]
gGroups thread: Compiling C Binaries for Android
Filesystem dump from Android running on SDK Emulator: gGroups thread discussion | Benno's blog post with files
reserved for Android installation instructions
[ reserved ] Hopefully we will get this far
polyrhythmic said:
I've also browsed threads, read the Wiki, studied up on the Hermes Linux project -- but things seem to have died since Feb 07
Click to expand...
Click to collapse
If you are interested in the facts, and not some google-related hype, please
check this one
http://www.handhelds.org/moin/moin.cgi/UniversalStatus
My Android News blog (now on Russian language)
English version cooming soon.
http://android.my1.ru
Now it is under construction
Much thanks cr2!
n00bs are everywhere I'm trying not to be one of them.
I have been doing a lot of reading, things have been quiet on the Kaiser front but that soon will change. I just read the #htc-linux logs from the past few days, see you there after work!
Charles
(sent from das Kaiser)
WoW!
Is this going to be like getting Linux OS on my Trinity? I like the browser but a lot of the apps in teh demo vid rely too much on 3G. Data rates in the UK are prohibitive at the moment so I stick with WIFI
welcome to join AndroidPort group
hello:
you are welcome to join the AndroidPort group, where the
idea is to make Linux and Android work on a real or virtual
hardware phone platform.
looks like you are quite advanced in this area. we would
welcome your presence and expert knowledge.
have a look at our website. you will find a lot of
information for this subject in 1 place.
AndroidPort
http://groups.google.com/group/androidport
Aaron
Cool initiative, will write about it in my next News collection.
polyrhythmic said:
Ok, there is plenty of speculation on Android and can we run it on our HTC devices, etc. I have started this new thread dedicated to the MSM7K Kernel release, and what it will take to get this running on our phones.
I would like this thread to become a resource, rather than just general theorizing. For example: "I know we need driver X to run Y on HTC device Foo." What I am not looking for: "Android is so l33t, plez tell me how to run on my Zaurus kthx". The difference is that the first example is constructive, and adds to the discussion.
The signal to noise ratio on the Android gGroup is terrible, and mostly consists of wild theorizing, self-promotion, and arguing. I have a feeling it will improve, but for now I'd like to discuss this subject away from all the SuperKoolNewAndroidForum.com forums.
My Goals for this Thread:
Establish what is known to work, and what the kernel is sorely lacking.
a) I know we have booted Linux on HTC devices, has it been done on the most current devices? (please link to thread/proof)
b) What are the main major roadblocks preventing Linux from being run on more HTC devices? (Obscure hardware design, bricking phone)
Compile a list of needed and helpful software for loading Android: bootloaders, useful Linux tools, filesystem images
Provide continual updates with photos/logs as we (hopefully) make progress
My bet is that the current 'gPhone' in the videos is an HTC device not unlike yours or mine. [link to my blog] IMHO, the hype over 'When will the first gPhone be released' is irrelevant, as Google has been working closely with HTC and Qualcomm for a long time -- and the specs for Android are so low, Google clearly expects to be able to run Android on existing hardware, without needing new hardware technology.
Of course, the tools and software we need are all in existence already, someone at Google is doing a good job of keeping their mouth shut. Therefore this is not an impossible task, just difficult, but I know you xda-hackers like a challenge! So, Let's go!!
Charles
FYI: I am aware XDA was founded with the Xanadux project, so this should be the perfect place to hack us a gPhone. I've also browsed threads, read the Wiki, studied up on the Hermes Linux project -- but things seem to have died since Feb 07, I'm hoping this latest development with Android will spark interest again, and we will be able to run Linux on our current, most powerful devices. I could make educated guesses about the state of the Xanadux project, but I'd rather hear it from XDA devs themselves who are most familiar.
Click to expand...
Click to collapse
where is the video?
anheuer said:
where is the video?
Click to expand...
Click to collapse
YouTube Your best friend , along with google obviously
POLL ENDS ON MONDAY (APRIL 25TH) AT 12:00 GMT
FIRST THING WE NEED DONE WILL BE TO GET CM/GINGERBREAD BOOTING regardless of the number of functions working
Dear SG3ians,
The time has come for us to take our beloved phone to the next level! Let's port Cyanogenmod (or gingerbread). I believe that if we unite this is a realistic possibility!
It might start off slow, it might take time, and there will definitely be hurdles to cross, but I know we can do this!
Who's with me!!
How was my motivational speech?
Ok, now lets get to more concrete stuff.
I suggest reading this (will update with link when able to. Go to cyangoen forums porting and read the sticky thread) and trying to follow this in our endeavor.
This is how suggest to proceed:
Phase 1:
Deciding what to port, getting a general outline of who will be involved, and planning+suggestions.
Phase 2:
Getting CM (or gingerbread) to boot and seeing what functions and what doesn't function
Phase 3:
Dividing up the non functioning work between devs/dev teams.
Phase 4:
Enjoying our "new" phones
I know this is a simplistic outline, but the sooner we start the sooner we finish.
For this to work it will of course require high interest within the community, it will also require civilized cooperation between members of the team.
Some other stuff (PLEASE READ BEFORE POSTING):
Please do not start posting posts like "I want CM too!" "+1 great idea for making the thread" "I'm interested how can I help"
Show your support by voting in the poll, more votes means you support this.
If you are interested in helping, say what knowledge you have and what you think you can do. For the time being I will start out with two main groups. Devs and testers. Testers will divided into alpha (will/can also test beta) and beta testers. Everybody involved (especially devs and alpha testers) have to say that they are aware of the risks (and be aware of the risk, duh ) that are involved in participating in this, and that all responsibility for any damages is all theirs. Devs will probably be furthered divided, but not at the present time. I will include the group potential devs (people who have some potentially useful skills/knowledge) for the time being. If potential devs dont become devs they will automatically be thought of as alpha testers, if you dont agree with this note it in you application post (and state if you want to then be considered as a beta tester or not participating at all if you dont become a dev). So if you wanna help post a post with one of the 4 choices and include the risk part (-only if you agree to it of course)
I have added the advisor group for people who dont have the phone but want to help with their knowledge
Any suggestion or ideas will be helpful, but try to check if somebody already proposed it, and if possible apply and suggest in the same post
I have made a dropbox for this project, if anybody knows/has a better alternative please let me know
User credentials will eventually be shared to select people (most likely only devs).
P.S. After I finish reserving, haree please move this to the dev section (if/when you are online)
P.P.S. If anybody is curious, this is stubborn_d0nkey. Thanks to clarkkov for inspiration
P.P.P.S. Latest CM means latest stable CM, not a nightly
IT IS OKAY TO POST NOW
Developers:
bhuvi - c, linux and core java
Potential Developers:
stubborn_d0nkey - some C, basic linux
AndroKite -medium linux/C (I'm assuming potential dev, if I'm wrong edit your post, or post a new one (but dont double post))
schopen80 -medium knowledge of linux, shell scripting, C and others
s3th.g3ck9 - (java)
powerpravin - drivers testing and a blazing fast brain
Can i help in the project?
Reserved, thanks for being patient!
wrong account, haree please delete this and the above post
@ above post. read the OP, read the bolded!
Alpha Testers:
CJHolder -basic linux
Pauri
jazux - very early alpha tester
Beta testers:
anant.0097 - maybe alpha tester
sekhargreen
chandradithya - maybe alpha tester
Advisors :
Helpful info:
Thread on cyanogenmod forums about general porting
Reserved, thanks for being patient!!
Reserved, thanks for being patient!!!
Reserved: YOU CAN POST NOW!
I'd like to be a potential developer. I have some knowledge of C and basic linux knoweldge. I am fully aware of all the risks, and I accept that I am responsible for all damages to my phone.
P.S. This is how an application post should look like
P.P.S. Basic linux does not mean that you are able to use linux for surfing and stuff, it means basic knowledge of more advanced linux stuff (ex. terminal)
I'd like to be a potential alpha/beta tester. I have some basic linux knoweldge. I am fully aware of all the risks, and I accept that I am responsible for all damages to my phone.
By Basic linux I mean I can use terminal etc. :L I use linux as my OS, Odin works fine in Wine!
CJHolder said:
I'd like to be a potential alpha/beta tester. I have some basic linux knoweldge. I am fully aware of all the risks, and I accept that I am responsible for all damages to my phone.
Click to expand...
Click to collapse
CJHolder said:
By Basic linux I mean I can use terminal etc. :L I use linux as my OS, Odin works fine in Wine!
Click to expand...
Click to collapse
Thanks!
(mostly for others)Listing knowledge/skills isn't that important for testers, and you dont really have to say what you mean by basic linux, I (I'm stubborn_d0nkey) just wanted to differentiate between two possible understandings of "basic linux" so people dont say basic linux when they take that as meaning day-to-day usage of linux (surfing, etc) since its not really helpful to the project
I want to help in the project I have some mediun linux knoweldge and C. I am fully aware of all the risks, and I accept that I am responsible for all damages to my phone.
I'd like to be a potential developer. I have medium knowledge of linux, shell scripting, C and others. I am fully aware of all the risks, and I accept that I am responsible for all damages to my phone.
You guys are doing a great job
But I must give some tips that I have
First try to do a sdk port
It just requires to take the boot.img from it and flashing it in FAST BOOT mode which we don't have
So there needs to be done other way
Secondly there are some threads which describe how to port cm to any phone
Take a look at them
Thanks,
cdesai
Talk to motofoca (mad-team)...he has ported gingerbread to g5...he can surely help...
http://Techass.wordpress.com
I read @Entropy512 write somewhere "we are more in need of developers than of testers at the moment"
To that effect I want to make an appeal to @maxwen @XpLoDWilD @Entropy512 @pulser_g2 and all other people who started the initiative to properly document out a few things
1. If a device maintainer wants to get his device added to omni ROM what should the steps be ?
2. To set up a omni ROM - compliant device tree what are the prerequisites. As in omniROM trees have been seen to be using a format of aosp.mk+custom.mk device makefiles where aosp.mk makes it AOSP-compliant and custom.mk is the omni additions. How custom.mk is to be made (a template maybe ?) should be be documented. In fact I would go out to say a device/custom/sample tree should be made as an example
3. Are there any guidelines as to how much the hardware side codes can be hacked with to make the devices supported ? (Many groups of developers have forks of hardware/qcom/* repos that are pretty liberally spread with #ifdef's and makes them break CTS/CDD in a huge way). How much will these hacks be supported ?
4. Obvious point, what are the fields in which you need help most badly as of now. That is to say ril/telephony experts are highly needed right now or are features the topmost priority or is the highest concern to make the hardware repos tip-top so that devices are completely stable
Also publishing some guides on how to get sources and build the ROM would be good too, but since you are looking for "Developers" right now, it can be assumed that they will figure that much out on their own at least
This documentation will be done.
Actually one of the key goals of omni is to properly document things.
Bear in mind exactly how early this is in the process - it was only yesterday we even made the links available for github...
Documentation will be a large part of going forward and it has been ongoing for a while. Currently that's the biggest task actually, much moreso than the actual development.
Developers don't only write code, they also write docs
To that effect, http://docs.omnirom.org is going to be the home
Among other things I want to do is a "patches for a given feature" document so it's easier to find out how a given feature (such as status bar brightness) was implemented.
I really want to do it before I have too many patches to put in there, but I also have tons of stuff to fix!
Entropy512 said:
Among other things I want to do is a "patches for a given feature" document so it's easier to find out how a given feature (such as status bar brightness) was implemented.
I really want to do it before I have too many patches to put in there, but I also have tons of stuff to fix!
Click to expand...
Click to collapse
What do you think about this idea? These common kernel patches could also fit into that document.
pulser_g2 said:
This documentation will be done.
Actually one of the key goals of omni is to properly document things.
Bear in mind exactly how early this is in the process - it was only yesterday we even made the links available for github...
Documentation will be a large part of going forward and it has been ongoing for a while. Currently that's the biggest task actually, much moreso than the actual development.
Developers don't only write code, they also write docs
To that effect, http://docs.omnirom.org is going to be the home
Click to expand...
Click to collapse
if I can be of any help let me know,
I would love to see this project start off right from the beginning with proper documentation about EVERYTHING
also +100 to @Entropy512 's idea. documenting each feature and how it has been added is really important
I strongly urge that submissions via gerrit should be enforced to have a well written description in the commit message too. (it is so much easier now with gerrit 2.7+ we can do it right inside our browser after the patch has been uploaded too)
championswimmer said:
if I can be of any help let me know,
I would love to see this project start off right from the beginning with proper documentation about EVERYTHING
also +100 to @Entropy512 's idea. documenting each feature and how it has been added is really important
I strongly urge that submissions via gerrit should be enforced to have a well written description in the commit message too. (it is so much easier now with gerrit 2.7+ we can do it right inside our browser after the patch has been uploaded too)
Click to expand...
Click to collapse
Yup. I've always tried to have a detailed commit message in anything I create, but I think we may need to start enforcing it so everyone does it.
Is there any kind of current features / bugs / patches list on the official build? Or even just a changelog?
orangekid said:
Is there any kind of current features / bugs / patches list on the official build? Or even just a changelog?
Click to expand...
Click to collapse
There are no official builds yet. Too early for that.
so much work to do.
Entropy512 said:
There are no official builds yet. Too early for that.
so much work to do.
Click to expand...
Click to collapse
Oh, I was under the impression there was a compiled "official" version for the N4, N7, etc...
No worries, in due time I'm sure. Be looking forward to the Nexus 5 build..
orangekid said:
No worries, in due time I'm sure. Be looking forward to the Nexus 5 build..
Click to expand...
Click to collapse
give us the device first
I follow Omni for the Nexus 5. Nightlies have started since Monday so I'd like to know if there's a general Omni changelog now or a specific one for each device.
I'm a developer without much ROM/Android development. I'd love to give a hand wherever possible, but like @championswimmer said, it's kind of overwhelming to jump in and help. I'm totally cool to be relegated to documenting things if that helps, but I also understand the interruption that it would cause for you guys to slow down long enough to explain what I need to know.
What I do have experience with:
Java
Jenkins
Minimal app development
Other crap that might or might not be helpful
I just wanted to let the XDA community know that I've started a bitbucket project to port PDFBox to android. The repository is available at bitbucket.org/mkmatlock/android-pdfbox
Currently, I've ported a subset of java.awt to support geometry and ICC color management classes (using apache Sanselan and the sun awt source code), and trimmed out unsupported functionality from PDFBox that depends on BufferedImage and other awt native classes.
I have tested some features including:
-Text Extraction
-Annotation Parsing
I assume that other features still work, but I have not been focusing my efforts anywhere else.
I would be very happy if people wanted to contribute to the effort by forking and submitting pull requests to the project.
I hope that this library becomes useful to the community. Currently, it is buggy, it is missing many PDFBox features, and it likely won't compile correctly when you first clone the repository, but I think we can put together a nearly feature complete port without killing ourselves over it.
Thanks for your interest.
Looks like Huawei has posted some source code online: http://m.huawei.com/enmobile/consumer/support/downloads/index.htm with the label: FRD-L04_MM_EMUI4_1_opensource
I'm downloading it now, hopefully it's something good and useful!
anks329 said:
Looks like Huawei has posted some source code online: http://m.huawei.com/enmobile/consumer/support/downloads/index.htm with the label: FRD-L04_MM_EMUI4_1_opensource
I'm downloading it now, hopefully it's something good and useful!
Click to expand...
Click to collapse
It's broken (as always, bunch of liars), I have uploaded it to github so you can download it at a decent speed: https://github.com/XePeleato/android_kernel_huawei_FRD-L04 (ignore build.sh, it's the script I use to build it)
EDIT: Fixed, as always, check github, I haven't tested it, but if you want me to upload a flashable .zip, I'd need your fstab file.
Thats a L04 version, will this work with L09 Dual Sim (32gb EU) version?
Syssx said:
Thats a L04 version, will this work with L09 Dual Sim (32gb EU) version?
Click to expand...
Click to collapse
There's just one way to know! But honestly, the kernel as it is now, doesn't have any improvement, however it might be useful for a developer who wants to code a custom kernel or something like that.
Glad it's in a buildable state. Now, let's see what else Huawei is going to release.
--I think I should wait until I post my reply --
Hey Guys,
Just so you know, I have a direct line at Honor and am able to make requests as it relates to releasing sources and specific documentation. I am not a developer myself, but you guys can feel free to make requests here and I'll bring it back to Honor. It's really important that we get to the point where custom ROM development and full modification is possible on the Honor 8!
svetius said:
Hey Guys,
Just so you know, I have a direct line at Honor and am able to make requests as it relates to releasing sources and specific documentation. I am not a developer myself, but you guys can feel free to make requests here and I'll bring it back to Honor. It's really important that we get to the point where custom ROM development and full modification is possible on the Honor 8!
Click to expand...
Click to collapse
Svetius, here's what I think we would need, @XePeleato or anyone else, please chime in also!
working kernel code - kinda have this XePeleato's work
device tree
full firmware images (for backup/restore use)
proprietary vendor files
documentation on the SoC
anks329 said:
Svetius, here's what I think we would need, @XePeleato or anyone else, please chime in also!
working kernel code - kinda have this XePeleato's work
device tree
full firmware images (for backup/restore use)
proprietary vendor files
documentation on the SoC
Click to expand...
Click to collapse
Why would you need a "device tree"? I can create a working one for you in 5 minutes. (I know what you mean, the HAL drivers are not inside the device tree, I'd try to be more specific if you want them to understand what you are asking for)
svetius said:
Hey Guys,
Just so you know, I have a direct line at Honor and am able to make requests as it relates to releasing sources and specific documentation. I am not a developer myself, but you guys can feel free to make requests here and I'll bring it back to Honor. It's really important that we get to the point where custom ROM development and full modification is possible on the Honor 8!
Click to expand...
Click to collapse
Cool, I'd love to talk to them personally, but since that doesn't look possible, I'd like to ask for some things (It feels like Christmas lol)
Specific documentation (Code snippets, a document... you know) about:
Their OpenGL implementationThe Hi110X communications IC (Integrated Circuit)The Audio systemThe Camera, other companies with the same sensor released their drivers source so it isn't Top SecretThe SePolicy
That would be a good starting point and in my opinion it's pretty reasonable.
XePeleato said:
Why would you need a "device tree"? I can create a working one for you in 5 minutes. (I know what you mean, the HAL drivers are not inside the device tree, I'd try to be more specific if you want them to understand what you are asking for)
Click to expand...
Click to collapse
My thought was, if we're asking, might as well go all out and get something like what OnePlus released for the 3. A full working device tree, kernel, etc.... http://www.xda-developers.com/onepl...-3-device-trees-and-kernel-sources-available/
anks329 said:
My thought was, if we're asking, might as well go all out and get something like what OnePlus released for the 3. A full working device tree, kernel, etc.... http://www.xda-developers.com/onepl...-3-device-trees-and-kernel-sources-available/
Click to expand...
Click to collapse
One Plus did went forward and released proprietary blobs for Dash charging that were supported on AOSP based ROMs. If Huawei don't want to release source codes for their OpenGL, Hi110x, composer, camera, etc implementations, then at least proprietary blobs free from EMUI crap that work with AOSP (this is the least I want; source code is always good as it means we don't have to depend on Huawei if things break or if we want to develop future versions of Android which if aren't released officially by Huawei).
anks329 said:
Svetius, here's what I think we would need, @XePeleato or anyone else, please chime in also!
working kernel code - kinda have this XePeleato's work
device tree
full firmware images (for backup/restore use)
proprietary vendor files
documentation on the SoC
Click to expand...
Click to collapse
From this list, what are the "must-haves"?
Would be nice for others to chime in.
svetius said:
From this list, what are the "must-haves"?
Would be nice for others to chime in.
Click to expand...
Click to collapse
The most important things we need are:
Proper documentation about the SoC and if possible, a Board Support Package for Kirin which will greatly boost development.
Proprietary blobs which don't include EMUI crap and Huawei's mistakes.
We already have the kernel source which thanks to Huawei was zipped in a non-case sensitive OS and the stock firmware images to extract vendor blobs (which don't work well with AOSP/CM).
hackslash said:
The most important things we need are:
Proper documentation about the SoC and if possible, a Board Support Package for Kirin which will greatly boost development.
Proprietary blobs which don't include EMUI crap and Huawei's mistakes.
We already have the kernel source which thanks to Huawei was zipped in a non-case sensitive OS and the stock firmware images to extract vendor blobs (which don't work well with AOSP/CM).
Click to expand...
Click to collapse
While in my opinion this is totally correct, it's also crucial to ask for reasonable stuff or Honor will think that We are just noobs asking for a 'git pull && make' solution, (that they will obviously not support).
I know this was anks' idea, but by asking for binary blobs ready to use with stock android, you are really telling them to code again a big part of their drivers and libraries. They won't do that since they are not going to put that much effort just to please us. Maybe We can suggest them to 'organize' their code for future phones.
XePeleato said:
While in my opinion this is totally correct, it's also crucial to ask for reasonable stuff or Honor will think that We are just noobs asking for a 'git pull && make' solution, (that they will obviously not support).
I know this was anks' idea, but by asking for binary blobs ready to use with stock android, you are really telling them to code again a big part of their drivers and libraries. They won't do that since they are not going to put that much effort just to please us. Maybe We can suggest them to 'organize' their code for future phones.
Click to expand...
Click to collapse
I guess I was dreaming way too much. I'm expecting too much from someone who has delivered nothing in the past. We'll keep it simple then. Honor, please release Kirin documentation, schematics and Board Support Package.
Both @hackslash and @XePeleato make great points. I guess I was going for a wish list, dream case option where they would be willing to put in some work for us. Realistically, I agree, good documentation and organized code will go a long way. Would it be possible to keep the lines of communication open? If there's an issue developers run into with the released code, if we can go back and ask for something additional/clarifications.
anks329 said:
Both @hackslash and @XePeleato make great points. I guess I was going for a wish list, dream case option where they would be willing to put in some work for us. Realistically, I agree, good documentation and organized code will go a long way. Would it be possible to keep the lines of communication open? If there's an issue developers run into with the released code, if we can go back and ask for something additional/clarifications.
Click to expand...
Click to collapse
I also have the same question. Since @svetius is going to be a middle man and he will carry our queries to the Honor, it would have been much better if a group of members at XDA who have experience with Kirin devices were selected and were allowed to do the talking. This way, that group could better address the problems faced in developing and the stuff which is need to implement Kirin's proprietary stuff.
Atleast there should be a separate thread here in XDA which is solely for the purpose of addressing all queries to @svetius which he would carry on to Honor. At this point, I am clueless what's happening with the partnership and if there has been even some communication regarding this between the two partners.
All this is pure marketing . How can you be a thread of a phone that does not own the source kernel ?
svetius said:
Hey Guys,
Just so you know, I have a direct line at Honor and am able to make requests as it relates to releasing sources and specific documentation. I am not a developer myself, but you guys can feel free to make requests here and I'll bring it back to Honor. It's really important that we get to the point where custom ROM development and full modification is possible on the Honor 8!
Click to expand...
Click to collapse
Setup a page on their website for developers like what SONY has been doing.
scafroglia93 said:
All this is pure marketing . How can you be a thread of a phone that does not own the source kernel ?
Click to expand...
Click to collapse
Of course We have the kernel source, go ahead and build CM with it.