Related
I apologize for my noobish question, but how are the ASOP builds starting to roll out w/o source being released?? I understand you can compile aosp builds on your own, but doesnt the source code provide all the tweaks you need to optimize it on a device to device basis?
There's no ICS source for the Captivate either, but we are officially supported on CM9. Very glad!
Sent from my Captivate using Tapatalk!
if there is good source from another device that is near this one then porting could be possible.
The short answer is a combination of two things based on what I can tell.
They are actually using the existing kernel for the leaked ICS roms and beginning to dissect them. As far as I know, the current AOKP roms being used are using either an unmodified original kernel from ULD3 or 'very slightly' modified/patched kernel from ULD3 with a few tweaks for overclocking support and whatnot.
As far as what is happening with the Captivate, I believe they are taking heavy sections from the Gingerbread source code and splicing it in to their ICS kernel and changing what they need to for ICS compatibility.
Also, similar devices that have ICS source code floating around can also be spliced up.
I am only speculating here since I am not involved in the projects, if someone knows more than I, feel free to speak up.
Hello All,
As you all know I've been part of Xda and assiting in a positive resolution from HTC in requests from Bootloaders to source codes. Well seeing we have a great device that seemed to be given EOL to early in its game.. in my opinion due to lack of marketing skills. Well I will be posting in HTC FB to get our voice out to them for the Source Code release for our device.
Please comment "Like" and comment to request this so we can continue development for the Flyer.
https://www.facebook.com/photo.php?fbid=10151213297764443&set=o.165420456859572&type=1&ref=nf
And Here:
https://www.facebook.com/photo.php?fbid=10151213304969443&set=o.101063233083&type=1&relevant_count=1
Um, source code of what? They release sources of Honeycomb, and there are no sources of ICS or Jelly Bean, so what's the whole point?
Source code for drivers which can be ported to ICS and JB. Anyway it helps coders make their own drivers for Camera/Front camera and for video
kayoma said:
Source code for drivers which can be ported to ICS and JB. Anyway it helps coders make their own drivers for Camera/Front camera and for video
Click to expand...
Click to collapse
Then we would need not just the drivers, but the whole 3.x kernel. I believe it's much harder to adapt ICS/JB drivers to GB/HC kernels
kayoma said:
Source code for drivers which can be ported to ICS and JB. Anyway it helps coders make their own drivers for Camera/Front camera and for video
Click to expand...
Click to collapse
Then we're asking the wrong ppl, it's not HTC. to understand this first you need to understand what makes up a ROM.
There is the kernel which is low level device specific, the kernel is mostly based on open source linux code, htc adds some board and device specific configuration on top of that.
Then there is the aosp which is also open source, an operating system provided by google that makes up most part of any ROM.
Then you have your aosp derivative like CM or AOKP, which provides board specific fixes and some customization. HTC's ROM is also based on aosp, but they add their own sense look and feel to it.
And finally and most importantly you have your close source proprietary drivers provided by chip manufactures like Qualcomm and TI. They control cameras, wifi, BT...etc. So in reality there is very little HTC could do as they don't have the rights to release these code. And that's is where most ppl run into issues.
So to create a ROM is not hard at all, anybody can download the source code and compile it to generate a ROM as most of the source code are all open source. What will be helpful is if Qualcomm releases the source code for their drivers, which I doubt they will ever do, otherwise they wouldn't be close source in the first place. The only thing we could do is try to reverse engineer the device base on logs and understanding of how each component should work and make educated guesses.
Due to HTC lack of effort on this device (No ICS - HC was slow joke) I will never buy another HTC product again, same goes for sony, though they did eventually update xperia x10i it was only due to huge pressure not because they wanted to.
I want to buy an electronic product that potentially remains relevant at least a year later otherwise forget it.
so i sent this letter to HTC
after reading this page where HTC discusses 4.1 upgrades i decided to drop them a line "
DIRECTLY FROM YOUR WEBSITE:
When will additional devices receive Android 4.1?
In addition to the HTC One X and HTC One S, we are actively reviewing our product portfolio to identify candidates to receive Jelly Bean. Our goal is to prioritize review for devices launched in 2012 with our numerous carrier partners across multiple regions and then consider our ability to provide updates to products from 2011.
What devices will not get Android 4.1?
We work hard to ensure each of our products has the optimal user experience and therefore some products will remain at their current version of Android. In general, devices with 512MB RAM or less will not be upgraded to Android 4.1. At present, these devices include the HTC One V and the HTC Desire C. As we identify other devices that will not be upgraded, we'll provide updated information.
What about a development version of Android 4.1?
For our developer community, we plan to make generic development ROMs of Jelly Bean available for both the HTC One X and HTC One S. As soon as the ROMs are ready, they will be posted to our HTCdev site (www.htcdev.com). We strongly recommend customers take the time to understand the limitations of the development software along with the terms and conditions on the site before downloading to their device.
REALLY!? have you listened to what your customers have asked/said about the HTC flyer at all?! where is OUR 4.1 DEVELOPMENT ROM! wtf! where are you for us!? I can tell you where... you are giving us 3.2 HC that takes away two very important features i bought the device for #1 GPS! completely broken by your newest update to HC. #2. Hardware Keys.... WHY?! i understand that HC introduced soft keys. so you say you "We work hard to ensure each of our products has the optimal user experience" BULL! you clearly weren't thinking about the end user when you pushed out that HC update for the flyer. Would have been smarter for you to leave us on working GB and go straight to ICS or JB when it was ready! this is lunacy! who ever is making decisions in your company needs fired. you are bleeding money from everywhere. why don't you bring it back to the old school HTC that CARED! ABOUT! IT'S CUSTOMERS! listen to what we are saying! hear our voice! we have signed petitions. we have pleaded on multiple forums. WE have poured over your FB and twitter pages asking for you to throw us a freaking bone here.... when is it gonna happen? ever?!
I still have my flyer and i love it dearly. but without updates it's falling behind the pack. I recently bought a 10.1 galaxy note. while i'm happy with it's speed and what not. it's not the form factor i want. which is what the flyer is for me. perfect. PLEASE DON'T GIVE UP ON US OR THIS DEVICE! PLEASE RELEASE A DEVELOPER ROM FOR OUR FLYER! "
this was their reply (you will want to read it for sure)
Dear Matt,
Thanks for contacting HTC!
We completely understand your concern and I thank you for your patience and am deeply sorry if this issue has caused you any dissatisfaction with HTC or its phones. I hope that it will not detract from your overall perspective of the device or the company. You are the most important part of the HTC Family.
We listen to our community and feedbacks like yours are the ones that make us revise our decisions, and try to find the correct balance between the device’s performance and usability. We cannot announce or say anything about the Flyer right now but what I can tell you is that we are, indeed, paying attention to the community´s feedback and opinions.
Should you require further assistance, please do not hesitate to contact us through http://www.htc.com/us/support/email-support or call us at +1-866-449-8358 from 6AM to 1AM EST, 7 days a week.
Have a great day!
Let me know if I have successfully answered your question, please click here to complete this.
To send a reply to this message, please click here.
Sincerely,
Carlos
HTC
I appreciate the passion here, but HTC left this device for dead along with the Jetstream and View shortly after releasing it. We received what would amounted to a Beta of Honeycomb then they closed up shop. You live and learn, and although I still use my Flyer and enjoy it I will not buy another HTC device
I completely agree with you .. HTC should give us ICS or JB for our Flyer as a good faith. We must keep GB because honeycomb is a joke..
I use my Flyer and i try as much as possible with the optimized news on GB .. and share with you.
Hoping for a good action on their part for JB!!
Fatal1ty_18_RUS said:
Then we would need not just the drivers, but the whole 3.x kernel. I believe it's much harder to adapt ICS/JB drivers to GB/HC kernels
Click to expand...
Click to collapse
so the kernel source for HC 3.2 that's in HTCDev,,that is NOT the entire kernel sourcecode?
i know it's an old thread but i am wondering...
gersto said:
so the kernel source for HC 3.2 that's in HTCDev,,that is NOT the entire kernel sourcecode?
i know it's an old thread but i am wondering...
Click to expand...
Click to collapse
that the honeycomb kernel .
doesn't do you much good for ICS or JB
yncconsulting said:
Then we're asking the wrong ppl, it's not HTC. to understand this first you need to understand what makes up a ROM.
.
.
.
Click to expand...
Click to collapse
You didn't understand I think. The drivers are part of the kernel. May they be compiled into the kernel itself or in form of modules. Drivers can be binary objects to be linked (already compiled) or source code which will be compiled when the kernel is built.
If you have the drivers source code there is a fairly good chance to get them running in newer kernels with some minor changes.
So from my point of view you will have a good chance to even get 4.2 up and running as long as you have the drivers source code.
Sent from my GT-I9100G using xda app-developers app
ktp1976 said:
You didn't understand I think. The drivers are part of the kernel. May they be compiled into the kernel itself or in form of modules. Drivers can be binary objects to be linked (already compiled) or source code which will be compiled when the kernel is built.
If you have the drivers source code there is a fairly good chance to get them running in newer kernels with some minor changes.
So from my point of view you will have a good chance to even get 4.2 up and running as long as you have the drivers source code.
Sent from my GT-I9100G using xda app-developers app
Click to expand...
Click to collapse
yeah, so my point is HTC publishes kernel source code, not drivers, they don't even own some of the drivers .,so you will never get that. You get a HC kernel ,that works with a HC blob set and you cannot build a working 4.xx kernel because you don;t have a 4.xxx blob set and HTC won't give you one because they have never written one and never will
DigitalMD said:
that the honeycomb kernel .
doesn't do you much good for ICS or JB
Click to expand...
Click to collapse
well they must be of some good since we have ICS/JB ROMs out there that are "mostly" complete, slick and usable, although slightly buggy, so obviously yeah i get that it doesn't solve all the issues we have, since some drivers are missing: as evident by the non-working FC, no hardware decoding for video, and semi-working BT
DigitalMD said:
yeah, so my point is HTC publishes kernel source code, not drivers, they don't even own some of the drivers .,so you will never get that. You get a HC kernel ,that works with a HC blob set and you cannot build a working 4.xx kernel because you don;t have a 4.xxx blob set and HTC won't give you one because they have never written one and never will
Click to expand...
Click to collapse
Not exactly. The kernel is also part of AOSP. And even if HTC does not supply the driver sources there is a slight chance to use old driver binaries or to have them reverse engineered by some genius dev. Hope is the last to die
Sent from my GT-I9100G using xda app-developers app
ktp1976 said:
Not exactly. The kernel is also part of AOSP. And even if HTC does not supply the driver sources there is a slight chance to use old driver binaries or to have them reverse engineered by some genius dev. Hope is the last to die
Sent from my GT-I9100G using xda app-developers app
Click to expand...
Click to collapse
Keep dreaming. Some of the best around have tried that path.
No the device kernel is not in AOSP, the base linux (ANdorid) kernel source resides there, but if you look at the build, it calls in device , vendor, OS verson and board specific components to make a complete build. All that hooks into the blobs (drivers and libs) to make up the device specific environment that allows Android version X.XX to run
DigitalMD said:
Keep dreaming. Some of the best around have tried that path.
No the device kernel is not in AOSP, the base linux (ANdorid) kernel source resides there, but if you look at the build, it calls in device , vendor, OS verson and board specific components to make a complete build. All that hooks into the blobs (drivers and libs) to make up the device specific environment that allows Android version X.XX to run
Click to expand...
Click to collapse
Thanks for clarification. So I was not wrong about the drivers, which are the device and vendor specific components. In other words if you can get the vendor to release their sources or make their chip/board manufacturers to release their sources is the only way to go. Seems a bit unrealistic though but who knows...
Sent from my GT-I9100G using xda app-developers app
All should email the HTCDev
Use this link http://www.htcdev.com/contact
They themselves posted on that link
https://www.facebook.com/photo.php?fbid=10151213304969443&set=o.101063233083&type=1&relevant_count=1
Takes just f**kin 5 seconds
May be they will listen some day
freworld said:
All should email the HTCDev
Use this link http://www.htcdev.com/contact
They themselves posted on that link
https://www.facebook.com/photo.php?fbid=10151213304969443&set=o.101063233083&type=1&relevant_count=1
Takes just f**kin 5 seconds
May be they will listen some day
Click to expand...
Click to collapse
+1
I plan to build Cyanogenmod 10 from source, however I have a few questions.
When compiling the kernel from HTC sources, I get two warnings along the line of "warning: (ARCH_MSM_KRAITMP && ARCH_MSM_CORTEX_A5)." I am assuming these are safe to ignore? Other than, it builds and completes fine.
I've never built from source any roms (and for that matter have only done minor programming some time ago), however I have an extensive experience in programming and want to give it a shot.
Is there any reason why it is not possible to build an unofficial port? Wouldn't having the kernel sources from HTC make the job easier? Anyone try this yet or have experience with porting to new devices?
I have next to no programming/hardware/software modding experience but I believe some devs are working on the RIL (radio interface layer) for this phone before they get a working CM10 on the DNA...
I could be completely wrong but just chiming in lol
You can probably build it and get it booting without too much hassle. But you won't have any connection whatsoever. That's where the ril comes in. But it hasn't been cracked yet, beck, idk if anyone's even working on it atm.
Sent from my HTC6435LVW using xda app-developers app
drewX2 said:
I plan to build Cyanogenmod 10 from source, however I have a few questions.
When compiling the kernel from HTC sources, I get two warnings along the line of "warning: (ARCH_MSM_KRAITMP && ARCH_MSM_CORTEX_A5)." I am assuming these are safe to ignore? Other than, it builds and completes fine.
I've never built from source any roms (and for that matter have only done minor programming some time ago), however I have an extensive experience in programming and want to give it a shot.
Is there any reason why it is not possible to build an unofficial port? Wouldn't having the kernel sources from HTC make the job easier? Anyone try this yet or have experience with porting to new devices?
Click to expand...
Click to collapse
You will probably get a couple errors during the build, nothing to worry about. If you get an error and the build stops then you know you have a problem.
Also, we have the kernel source from HTC. Building custom kernels is a necessary step before we can build CM, but it doesn't really make anything easier. Like Bigandrewgold said, the RIL is the most important missing link at this point.
I wish you the best on this project, and you have a great community here of people who can help you out.
I myself would love to test out CM on this beast, ril or not. It'd be nice to have a build ready that we could just drop a kernel into.
Sent from my HTC6435LVW using Tapatalk 2
Hey all
After about 4 years with IOS phones ( primarily for game development) ; I finally hopped back on a phone I could stomache and enjoy tweaking.
My apologies in advance if this is obvious somewhere in the sub-forums (but I couldnt find the answer) .
After testing a few ROMS I settled into Jedi XV12 w/ Perseus Kernel and love it with the Nova Prime Launcher.
I would love to start working from this base ROM to try my hand at a GSM (with working data/4G/LTE) version that incorporates APN and other radio/network specific tweakability. The idea of a single device that I could use on TMO/ATT/VZW/SimMo/Straight Talk & **maybe Sprint ughhh* is too tempting after living in the Apple Walled Garden of Pain.
I have my environment setup on a MacAir (Ubuntu 64Bit in Fusion) and also a Desktop native Ubuntu 64Bit with Eclipse/SVN/GIT etc etc along with the Samsung source and Vanilla 4.2.1.
Does anyone know if JediXV12 has a repo I can pull/merge against? Or even JellyBeans B13? Ideally a full source tree pre-merged would be fantastic to jump right in.
As some background on me: I have been doing everything from C,C++, Objective C , Python & RoR for over a decade.... pushing 15 years now Mobile games development since 2007 ..........
Would love some feedback or help as I havent dug into android other then just 2 games a few years ago.
BTW: This is simply the best multipurpose device I have used in ages. From speed to the AMAZING black levels AMOLED gives !
Anyone... Anyone... Bueller... Bueller...? Lol
Sent from my SCH-I605 using Tapatalk 2
The only ones with full repos are going to be the AOSP ROMs. The others are primarily made through decompiling the Samsung code, editing the smali, and recompiling, and they aren't required to publish the source for their development since the only part of Android that's actually covered by the GPL is the kernel.
shrike1978 said:
The only ones with full repos are going to be the AOSP ROMs. The others are primarily made through decompiling the Samsung code, editing the smali, and recompiling, and they aren't required to publish the source for their development since the only part of Android that's actually covered by the GPL is the kernel.
Click to expand...
Click to collapse
Thanks for the reply Shrike. That's what i figured as well, but was hopeful that a full source code tarball or zip would give me a leg up to ensure a stable codebase merge with the current Jedi XV12 to add support for Domestic APN's and the such via updates from one of my servers to mitigate APN changes /updates/variances for specific carriers 3G/4G/HSPA+/LTE settings.
I'll hit up Jedi devs and see if they are interested in a hand with adding these features I suppose.
Yes yes, you may think that I'm crazy for attempting to compile AOSP, but in fact im just obsessed with getting AOSP to work (on my previous device I spent a full year on it without success), thanks to the experience I know much more know about the environment.
I've done several pure aosp builds so far, and they result in a ~280mb system folder, which is kinda the size of aosp I guess (atleast for xxhdpi)
But they end with errors of course, anyways. I used the devices specs with updated overlays,and added dependencies (such as hardware) to the environment.
But since the aosp environment is very mean to new devices its once again a real struggle. as expected, but I like the challenge.
Anyways, Im currently trying out this hybrid-ish environment. which contains the items listed above but with several elements of the AOKP environment added (only the essential ones for compatibility).
Compiling goes so far so good. hope I will get a working build. (don't expect this to happen tho)
Oh and since samsung is releasing the S4 Google Edition (AOSP) soon it must be possible. (the google edition is the qualcomm varian afaik)
More info soon!
I'm going to drop this here for now until I have time to mess with it more.
https://groups.google.com/forum/?hl=en#!topic/android-building/_F67iLDcVzQ
Note: This leads me back to my previous question as to how we are supposed to build with this.
At face value it seems we're only getting fairly close to what we were with other OSRC releases.
Going to look at more later tonight.
Skilled devs can get pure aosp to work properly. It was done for sprints gs3 without using CM code.
Sent from my SPH-L720 using Tapatalk 2
You don't necessarily need proprietary binaries to be released to build AOSP, although it does make it much easier. Sometimes you have to resort to trial and error and debug tools.
drewX2 said:
You don't necessarily need proprietary binaries to be released to build AOSP, although it does make it much easier. Sometimes you have to resort to trial and error and debug tools.
Click to expand...
Click to collapse
I disagree completely. Without the prop' libraries and drivers that the OEM has built to manage the board you can most certainly expect the related hardware to fail or be only partially functional at best. Some other 3rd party generic driver would still be required if this example were true. In the good old AOSP days (maguro for example) had roughly a dozen proprietary files required for the device tree to build. With more and more OEMs making different hardware configs and spin-off APIs trying to lock down a lead in the game it has inflated that number greatly. In this instance, for example, S4 requires roughly 165 proprietary files in the vendor/ and device/ tree. Furthermore, with many of those stacks being required to pass for a successful boot complete (audio for example) there is little chance for even semi-functional usage without the required libraries and drivers.
broodplank1337 said:
(edit)...I'm crazy for attempting to compile AOSP...
Click to expand...
Click to collapse
We're compiling pure AOSP already for this board. I'm not sure what your repo structure looks like but if you are based off a CM or AOKP base clone then you got some work cut out for you. The CM tree compiles completely different than AOSP. All EaglesBlood builds are compiled from our same main branch, which consists entirely of only pure AOSP + our own EB coding. There is no CM codeblock nor anything else polluting (no pun). Since CM and others have some custom hybrid APIs and such you may run into issues that are difficult to resolve or even identify. If you aren't the one committing those patches then it is difficult to know at a glance of what has been heavily CM-ified vs closer to native code; or unless you're very in-tune with CM, gerrit and GIT.
We'll be releasing AOSP 4.2.2 as soon as we get the kernel config where we want it to be. Stay tuned. http://www.eaglesblood.com
oOo B0XeR oOo said:
I disagree completely. Without the prop' libraries and drivers that the OEM has built to manage the board you can most certainly expect the related hardware to fail or be only partially functional at best. Some other 3rd party generic driver would still be required if this example were true. In the good old AOSP days (maguro for example) had roughly a dozen proprietary files required for the device tree to build. With more and more OEMs making different hardware configs and spin-off APIs trying to lock down a lead in the game it has inflated that number greatly. In this instance, for example, S4 requires roughly 165 proprietary files in the vendor/ and device/ tree. Furthermore, with many of those stacks being required to pass for a successful boot complete (audio for example) there is little chance for even semi-functional usage without the required libraries and drivers.
I think you misunderstood what I said. First of all, I am speaking from *experience*. I have ported AOSP to devices without RELEASED proprietary binaries and I have handled every step in porting; from display, audio, to calling, wifi, bt, etc. Released means the manufacturer provides a nice little package for you. I had to in many cases, figure out which libs from a stock rom were needed. Additionally, you can utilize libs from completely different devices as a temporary patch. I am very comfortable with kernel development and the android framework. If you were too, you would know what I am saying is true. Here is one tip, nearly every board is like another (within the same class; eg. MSM8960, APQ8064) with only slight variations (e.g. modem). Once you understand that, it becomes easier.
We're compiling pure AOSP already for this board. I'm not sure what your repo structure looks like but if you are based off a CM or AOKP base clone then you got some work cut out for you. The CM tree compiles completely different than AOSP. All EaglesBlood builds are compiled from our same main branch, which consists entirely of only pure AOSP + our own EB coding. There is no CM codeblock nor anything else polluting (no pun). Since CM and others have some custom hybrid APIs and such you may run into issues that are difficult to resolve or even identify. If you aren't the one committing those patches then it is difficult to know at a glance of what has been heavily CM-ified vs closer to native code; or unless you're very in-tune with CM, gerrit and GIT.
We'll be releasing AOSP 4.2.2 as soon as we get the kernel config where we want it to be. Stay tuned. http://www.eaglesblood.com
I agree with you on some points about CM code, however, you're group has been porting devices that were working or nearly working with base android code. Talk about an easy route. I can see you haven't had to do any hard work yet. Going from 4.1 -> 4.2 on a non google AOSP supported device or a device that has no CM build available for it is a whole different story. How do I know? I've done it. I was the first to build CM for HTC DNA and both CM/AOSP for Oppo Find 5. Next time before you "completely disagree," make sure you know what you're talking about.
Lastly, although I agree with you on some points about CM code, you should give them credit because your stuff is probably based on their stuff more then you lead others to believe; like nearly every other "dev group" out there. And by no means, am I some CM lover (I've had my quarrels with them), but you should give respect and credit to those who make what you do possible.
Click to expand...
Click to collapse
See Above.
drewX2 said:
I think you misunderstood what I said. First of all, I am speaking from *experience*. I have ported AOSP to devices without RELEASED proprietary binaries...
...How do I know? I've done it. I was the first to build CM for HTC DNA and both CM/AOSP for Oppo Find 5. Next time before you "completely disagree," make sure you know what you're talking about.
[/QUOTE
Great, hi-five to you, but before making bold assumptions...
http://www.xda-developers.com/android/aosp-jellybean-build-for-the-t-mobile-g2x/
drewX2 said:
...(CM) you should give them credit because your stuff is probably based on their stuff more then you lead others to believe; like nearly every other "dev group" out there. And by no means, am I some CM lover (I've had my quarrels with them),....
See Above.
[/QUOTE
I never suggested anything about CM, they are top-notch. I said we dont use their base code like "every other dev". Sorry you have had quarrels; and there is nothing "probably based off them" as I just told you our repo is straight AOSP & EB.
Likewise you should "know what you're talking about", prior to making assumptions and speculations.
^read above
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Im currently working on this as well...anyone have anymore success? Im currently fighting my way through compile errors...but I would love to be able to atleast get a bootable pure aosp from source...ill keep at it...but if anyone has gotten it yet please help speed up my process and enlighten me on what you did to compile a working aosp
Sent from my SAMSUNG-SGH-I337 using Tapatalk 2
I guess we all are I'm working on one too. Lots of research on correcting errors
Cm10.2 anyone??
Sent from my GT-I9505G using Tapatalk 2
deleted
Wrong post
I did it successfully with help of some external repos
forum.xda-developers.com/showthread.php?t=2397511