Related
As long as a Rom doesn't include googlebits it should be fine on google code right? It would be nice to use for bug tracking and a quick downloading service.
Doubt it, since I imagine that a lot of bits are closed-source and harvested from existing ROM dumps and so forth.
I believe quietblongs was the only dev here that actually built his roms from source. With that said. I mean the entire thing except some libs. But I'm not sure if anyone else is doing this. I think most of the aosp roms we have are ports with maybe compiled frameworks from source. Again that's just a guess.
But speaking of quietblongs... I wish he'd come back and make us a bad ass 2.1 aosp build.(a hint to quiet to build us another bare bones build)
I have a "generic" 2.1 AOSP build. The problem is getting the HTC vendor/oem stuff incorporated. I have tried following Cyanogen's lead with his "vendor overlay" in git, also borrowing from Lox's GSM hero stuff, but when I build it that way ((via "lunch htc_heroc-eng") I still end up needing to manually copy the proprietary files one-by one into build to get a resulting system.img. In other words, I'm missing a script that should do this during the build. Since nobody seems to be building for CDMA hero (I find directions for dream, magic, and nexus only), I basically don't trust my result enough to upload for others.
Building 2.1 as "generic-eng" is trivially easy, we could have a "nightly build" setup if we wanted. But getting the vendor stuff properly incorporated into the build (and having the build use these files to generate its source) is not a clear process to me yet. I'm learning but it takes time I don't always have.
On a side note, maybe someone could comment on whether a fresh build with the vendor stuff could/would solve ongoing issues like the camera or whether that is a 2.7/2.9 kernel issue that needs a backport.
5tr4t4 said:
I have a "generic" 2.1 AOSP build. The problem is getting the HTC vendor/oem stuff incorporated. I have tried following Cyanogen's lead with his "vendor overlay" in git, also borrowing from Lox's GSM hero stuff, but when I build it that way ((via "lunch htc_heroc-eng") I still end up needing to manually copy the proprietary files one-by one into build to get a resulting system.img. In other words, I'm missing a script that should do this during the build. Since nobody seems to be building for CDMA hero (I find directions for dream and magic only), I basically don't trust my result enough to upload for others.
Building 2.1 as "generic-eng" is trivially easy, we could have a "nightly build" setup if we wanted. But getting the vendor stuff properly incorporated into the build (and having the build use these files to generate its source) is not a clear process to me yet. I'm learning but it takes time I don't always have.
On a side note, maybe someone could comment on whether a fresh build with the vendor stuff could/would solve ongoing issues like the camera or whether that is a 2.7/2.9 kernel issue that needs a backport.
Click to expand...
Click to collapse
Yeah u will always need proprietary files to build aosp. That's what vendor is for. I've started gathering and trying to setup a community vendor for cdma heros. But just been to busy to finish. Will try soon though an put it on github for all to use.
But as for camera drivers and stuff like that. Ur gonna find that making libcamera build isn't gonna happen as of yet in 2.x aosp. Because it is broken as of the moment and doesn't make. The only solution to gettin camera into an aosp build is to use the libcamera and other camera libs from mine and Flipz HTC Rom. But even then ur gonna need a compatible kernel camera driver to work with it. As of now we haven't got that working fully. But also even once we get the driver working ur gonna have issues in aosp builds with camera as the gsm hero devs have found. As it stands now the aosp camera doesn't fully support our camera. Leaving them left with a 3m camera and I believe no video. It seems that HTC did some extra work in their camera.apk to finish up and give full support for our camera. The problem with that and aosp is like most HTC apks work in and with a HTC modified frameworks. So it goes deep into the framework.jar and many other frameworks files. I won't say it can't be hacked in some how but I will say it won't be easy. But if u manage to pull it of please share because a lot of devs have tried and haven't managed to pull it off as of yet.
Maybe you can point me in the right direction. Attached is my "vendor overlay" attempt. In the first case it's just Lox's stuff for hero with "heroc" in all the right places. The "extract" script is mine, modified by me given Cyanogen's nexus overlay example.
If you can create a git of a proper overlay, that would be great. Even if, as you say, it doesn't get us all the way to a working AOSP ROM.
Lox's language in his extract script is like Cyanogen's in his git repo, ie "who the hell knows if this is right, just guessing". So in that spirit, here is my attempt: a little experience mixed with vendor hatred mixed with voodoo
Feel free to correct me as you can, I would be grateful for a leg up from someone who has been at this longer.
P.S. I can't believe I had to "zip" up a tar.gz tarball to get it to attach to a dev forum (Invalid file). Man, I'm getting old.
P.S.S The included "kernel" file is a zImage I built from your toastcgh 2.7 sources in git. The wlan.ko was built against that...I should double-check that fact...
Ah well, maybe when they redo the forums here they'll think about bug tracking etc but I doubt it.
I did build my aosp rom from source, just built it using the gsm hero's vendor tree, made small adjustments to it for the heroc files. so yea, my rom is from google code to answer the OP's question.
darchstar said:
I did build my aosp rom from source, just built it using the gsm hero's vendor tree, made small adjustments to it for the heroc files. so yea, my rom is from google code to answer the OP's question.
Click to expand...
Click to collapse
EDIT: OHH, I completely misread your thread title, I probably could use google code for my aosp rom to track bugs
darchstar said:
EDIT: OHH, I completely misread your thread title, I probably could use google code for my aosp rom to track bugs
Click to expand...
Click to collapse
Right, I think we all misread it, I believe he was asking why we don't host our code somewhere, like Google Code, with a real bug tracking system, versioning controls, etc. He's got a great point, actually. It would be very nice to have a shared AOSP space, somewhere to see the files and track the issues and changes. ROM development based on AOSP could go on as usual on XDA with that base.
5tr4t4 said:
Right, I think we all misread it, I believe he was asking why we don't host our code somewhere, like Google Code, with a real bug tracking system, versioning controls, etc. He's got a great point, actually. It would be very nice to have a shared AOSP space, somewhere to see the files and track the issues and changes. ROM development based on AOSP could go on as usual on XDA with that base.
Click to expand...
Click to collapse
I got it
The issue is that Google Code won't allow you to host anything you don't have the right to distribute.
5tr4t4 said:
Right, I think we all misread it, I believe he was asking why we don't host our code somewhere, like Google Code, with a real bug tracking system, versioning controls, etc. He's got a great point, actually. It would be very nice to have a shared AOSP space, somewhere to see the files and track the issues and changes. ROM development based on AOSP could go on as usual on XDA with that base.
Click to expand...
Click to collapse
It would minimize on duplicate bug reports at least.
jonnythan said:
I got it
The issue is that Google Code won't allow you to host anything you don't have the right to distribute.
Click to expand...
Click to collapse
Understood, but the proprietary stuff can be pulled from the phone and/or from official releases for other HTC devices given the right script. That's why we need the vendor overlay.
I suppose the follow up question is, "why not just contribute to Android's AOSP core code in git, why create a forked AOSP repo?". That might be right, but we still need the overlay to pull the right files from the device. Perhaps taostcfh or quietblongs or darchstar already have this stuff ready and I'm just late to the game (probably ). Fine, I'd love to see that work so I can help out where possible.
<mini-rant>
This OEM/vendor crap really sucks...should I just repeat what has been said everywhere (and knocked down for very sound business reasons): Google should have released Android under GPL.
</mini-rant>
5tr4t4 said:
Right, I think we all misread it, I believe he was asking why we don't host our code somewhere, like Google Code, with a real bug tracking system, versioning controls, etc. He's got a great point, actually. It would be very nice to have a shared AOSP space, somewhere to see the files and track the issues and changes. ROM development based on AOSP could go on as usual on XDA with that base.
Click to expand...
Click to collapse
Exactly, thanks.
What keeps one of us from leasing a server to share for our (XDA) own CVS, bug-tracking and compiling?
ffolkes said:
What keeps one of us from leasing a server to share for our (XDA) own CVS, bug-tracking and compiling?
Click to expand...
Click to collapse
The fact that someone has to pay for it.
jonnythan said:
The fact that someone has to pay for it.
Click to expand...
Click to collapse
I've got a server but I'm not too familar with CVS, if anyone wants to lend a hand...
ffolkes said:
I've got a server but I'm not too familar with CVS, if anyone wants to lend a hand...
Click to expand...
Click to collapse
I have one too, but I would advocate for something more public, like git or sourceforge or Google Code, XDA, etc. You would want to make sure that you were gaining sharing capabilities and not just isolating yourself...either from upstream improvements or from other community stuff here and on other forums. A thousand people sharing is better than 10-20 people with a server, IMHO XDA has already proven that.
Plus, getting a development server going with all of the niceties of CVS et al is not easy...and there are ready-made solutions already available. None of this addresses jonnythan's point that some of this development is in legal limbo...what happens when someone , even by accident, pushes the google bits onto your public server?
...maybe you would get a cease and desist letter and become famous, LOL.
5tr4t4 said:
...maybe you would get a cease and desist letter and become famous, LOL.
Click to expand...
Click to collapse
Someone needs to combine the power of a forum with the legal protection of a public download site and the bug tracking of google code.
Apparently, I'm too lazy to code that all myself
Hi all!
I'm sort of new here, although i've been reading forums for quite some time now.
I have a Galaxy S (the main reason i'm here in the first place), and given i have a programming experience on different platforms i figured - what the hell. I am planning to try myself in Android apps development and possibly get down to custom ROMs and all that jive.
It is obvious where i should start with development (e.g. download SDK, read some tutorials, books etc.). As for messing with ROMs, i couldn't find an easy introduction to that. I mean, come on, everyone can root the device and install Voodoo lagfix (as i did already), but actually *creating* these ROMs is another story. If someone could possibly point me in the right direction (i just don't know where to start) it will be very appreciated.
P.S. I'm not your usual noob. I am neither afraid of command line, nor technicalities that are involved with this, and i completely understand that this will require HELL OF A LOT of reading, understanding, learning, and i completely understand that all this is way above my current knowledge, that's why i'm interested in the first place.
I think a good start would be to search tutorials for "deodexing" as this is one of the methods to prepare a ROM. From there it should lead you deeper into the rabbits burrow.
Thanks for the tip. Now i have questions that are probably belonging to the Chef section (started to read threads in there and realized that i should have started reading that section in the first place), but anyway.
If i compile the AOSP from source - will it work straight away on any device? Probably not, as the hardware needs drivers and stuff. So, next thing is drivers. As my device is Galaxy S, you can assume that all i ask is related to that device.
I saw that the open-source package (including the drivers) for Galaxy S has been released by Samsung. Does that mean that i can take Eclair AOSP source, copy the drivers, compile and use the result on my device? Well, probably Samsung made some modifications to the kernel, so it would be good idea to copy the kernel source too (i have never done kernel development before but i hope i have a somewhat general idea of how things work down there).
Anything else i need to be aware of?
Following the advice given earlier, i have googled for deodexing and ended up having a folder full of apk's. Does that mean that if i wish to install some Samsung stock apps (like camera) - i can take these apk's and install them as a regular app (or even include them in a resulting vanilla android ROM)?
i would love to learn how to incorporate this functionality into a rom (i'm an owner of a htc phone and primarily use sense roms). from what i've read, it's only a matter of adding a couple of files (phonewindowmanager$12.smali and phonewindowmanager$13.smali) and modifying phonewindowmanager.smali. if done right, this functionality can be added to any rom.
i've been comparing the cm7 smali file to a sense smali file to see what the differences are in terms of code but it just makes my eyes go wonky since i know nothing about reading/writing code.
until yesterday, i had no idea how to extract classes.dex from android.policy.jar nor was i aware of any of the information mentioned above. in other words, i'm a noob at this. i would like to learn how to do this and by the looks of it, many others on the forum are interested as well.
is there a dev out there that would like to share his/her knowledge/wisdom/experience on this with the rest of the xda community? i realize this is a lot to ask but i thought i'd try. thanks in advance.
I'd also be interested in this, for phones where Cm7 isn't available
Me too. Am going to put this thread as my signature until some kind soul comes up with an tutorial. Or at least a rhetoric answer.
By the way, the only guy that i know is, Andy Thompson, who's always update his mod/hack for MIUI roms
http://miuiandroid.com/community/threads/mod-skip-track-via-volume-press.7356/
and also CosmicDan
http://miuiandroid.com/community/th...hold-volume-to-skip-tracks.17381/#post-131527
Must have skill/mod/hack or even app for music lover and flashaholic.
Alright, I'm quite interested in building custom roms (I'm ready for the requisite "That's difficult you can't do it" type thing, however I can't learn unless you tell me what's up). Lets say I downloaded AOSP and I wanted say add the Cyanogen Theme Engine, or some feature from some random ROM, how would I do that? Git, Right? Probably, but how would I know what part to download? And once I do download it how would I implement it into AOSP? Also, is there a place where different ROM pieces are kept that I can download and add to my ROM?
I apologize for lack of terminology.
Darkfire5900 said:
Alright, I'm quite interested in building custom roms (I'm ready for the requisite "That's difficult you can't do it" type thing, however I can't learn unless you tell me what's up). Lets say I downloaded AOSP and I wanted say add the Cyanogen Theme Engine, or some feature from some random ROM, how would I do that? Git, Right? Probably, but how would I know what part to download? And once I do download it how would I implement it into AOSP? Also, is there a place where different ROM pieces are kept that I can download and add to my ROM?
I apologize for lack of terminology.
Click to expand...
Click to collapse
http://forum.xda-developers.com/general/xda-university
I was doing research on android's Biometric authentication .As we know back in android Marshmallow(6.x.x) we got native support for fingerprint recognition/fingerprint authentication.Not too long samsung started giving new way to unlock devices iris scanner in s8/s8+ last year,so it's there own implementation in S/W and so main problem is you cant use their implementation in any custom rom because AOSP upstream does not supports it.Now from Android Pie onwards they deprecated FingerprintManager API and bring us new BiometricPrompt API,means we can use other methods like iris,face recognition and other methods for unlock/authentication.Probably iris or face recognition might come in coming pixel.
So my main point of making this post is to discuss about the existing device with proprietary sensors like in galaxy s8/s8+/s9/9+,note8/9,mi8,poco f1 etc etc! .
Will we able to get those existing sensors work on custom roms?as far source code is concerned ,we got whole device code of POCO f1(i am not sure about IR face reco).
one thing i want mention:-i remember galaxy s5 released with android 4.4.x,which clearly dont have FingerPrintManager Api,but some smart dev xda managed to get that sensor working on android M based custom ROM .Sooooo maybe we will able to get our,s face IR working in next iteration of android pie.
I am learning about the android"s arch(also learning how to develop custom roms from scratch)
So devs on xda who have knowledge ,must share .i am always ready to learn
topics i refer for case study:-
https://source.android.com/security/biometric/
https://www.xda-developers.com/iris-scanners-native-support-android-p/
https://www.xda-developers.com/android-p-new-biometrics-api/
Help me out! I can only REPLY to threads, I can not POST such one!
thetripleS said:
Help me out! I can only REPLY to threads, I can not POST such one!
Click to expand...
Click to collapse
Bro you are new member, so don't have permission to post, go read xda's rules and terms of XDA. And secondly do a Google search for your problems and stop spamming irrelevant replies
Please!
Jaskirat singh said:
Bro you are new member, so don't have permission to post, go read xda's rules and terms of XDA. And secondly do a Google search for your problems and stop spamming irrelevant replies
Please!
Click to expand...
Click to collapse
Sorry for inconvinience, I digged google, i couldnt find anything! Please tell me when can i start posting questions?? Its true that i am a new member and i started XDA today itself.
thetripleS said:
Sorry for inconvinience, I digged google, i couldnt find anything! Please tell me when can i start posting questions?? Its true that i am a new member and i started XDA today itself.
Click to expand...
Click to collapse
Go here you get an idea which sub-forum you need to post
https://forum.xda-developers.com/poco-f1
.
RUPESHBW said:
Who are you to tell him what to do xda is about sharing tech knowledge there is nothing wrong in posting by new member. He giving his knowledge i had question with his argument above i got my answer. If you cant let other not demotivate.
Click to expand...
Click to collapse
If have you anything related to my topic then most welcome.
And who "ARE" you to correct me.
I didn't say anything offensive to him and secondly i told him to read to rules and terms.
And yea i was not demotivating him, its you who judging here.now stop arguing.
Please :- "STICK WITH THE TOPIC!"
Jaskirat singh said:
If have you anything related to my topic then most welcome.
And who "ARE" you to correct me.
I didn't say anything offensive to him and secondly i told him to read to rules and terms.
And yea i was not demotivating him, its you who judging here.now stop arguing.
Please :- "STICK WITH THE TOPIC!"
Click to expand...
Click to collapse
Oh its you posted this thread i forgot sorry didnt see i thought somebody just delete this arguments :laugh:
RUPESHBW said:
Oh its you posted this thread i forgot sorry didnt see i thought somebody just delete this arguments :laugh:
Click to expand...
Click to collapse
Its ok :/
Jaskirat singh said:
Will we able to get those existing sensors work on custom roms?as far source code is concerned ,we got whole device code of POCO f1(i am not sure about IR face reco).
Click to expand...
Click to collapse
Correction: we do not have whole device code. Nobody ever gets whole device code.
We have kernel source, but it is missing something. Mostly audio and wifi stacks. Wifi is easy to fix thanks to CAF, but audio is more difficult.
Making custom ROM's takes time because it is one big experimental process to get AOSP to work with existing blobs (pre-built binaries from vendor for hardware access) because we don't have the source code.
For IR Face recognition, there would have to be a driver in kernel for the camera, definitely. But that doesn't make it a given that custom ROMs can use it. It may also be missing in kernel sources, like wifi and audio is missing.
Ideally, when Poco gets Pie official update, yes - it will use the biometrics API, meaning that custom ROM's should be able to interface with stock blobs to also support it - this is achieved in much the same way as experimenting to get all the other hardware working. But it's impossible to know for sure until actual official Pie comes.
Most of this stuff relies on CAF, probably. If the kernel driver for the IR camera is found, or included in kernel source (don't know if it is but my guess is no), then they will have something to work on.
I think it's a bit early to speculate on such things now, since there is no public announcement from the community of any AOSP release based on Oreo yet, even.
CosmicDan said:
Correction: we do not have whole device code. Nobody ever gets whole device code.
We have kernel source, but it is missing something. Mostly audio and wifi stacks. Wifi is easy to fix thanks to CAF, but audio is more difficult.
For IR Face recognition, there would have to be a driver in kernel for the camera, definitely. But that doesn't make it a given that custom ROMs can use it.
Ideally, when Poco gets Pie official update, yes - it will use the biometrics API, meaning that custom ROM's should be able to interface with stock blobs to also support it. But it's impossible to know for sure until actual official Pie comes.
I think it's a bit early to speculate on such things now, since there is no public announcement from the community of any AOSP release based on Oreo yet, even.
Click to expand...
Click to collapse
i was wandering around and testing some things with this device.
Yes! That ir receiver(sensor) IS behaving as camera (which is not a color sensor only takes IR as input)
For testing i used miui hidden settings app
Go to hardware test(CIT)>52.ir camera.
And voila! You can see output on screen what this sensor sees
NOTE:- you can open this CIT settings if you tap kernel version number times, but you won't get that "ir camera" option, soooo you have to install that app
Btw anyone working or creating device tree for this device?
Well yea xiaomi is notorious for not giving up whole source, that's kinda bytuh thing
CosmicDan said:
Correction: we do not have whole device code. Nobody ever gets whole device code.
We have kernel source, but it is missing something. Mostly audio and wifi stacks. Wifi is easy to fix thanks to CAF, but audio is more difficult.
Making custom ROM's takes time because it is one big experimental process to get AOSP to work with existing blobs (pre-built binaries from vendor for hardware access) because we don't have the source code.
For IR Face recognition, there would have to be a driver in kernel for the camera, definitely. But that doesn't make it a given that custom ROMs can use it. It may also be missing in kernel sources, like wifi and audio is missing.
Ideally, when Poco gets Pie official update, yes - it will use the biometrics API, meaning that custom ROM's should be able to interface with stock blobs to also support it - this is achieved in much the same way as experimenting to get all the other hardware working. But it's impossible to know for sure until actual official Pie comes.
Most of this stuff relies on CAF, probably. If the kernel driver for the IR camera is found, or included in kernel source (don't know if it is but my guess is no), then they will have something to work on.
I think it's a bit early to speculate on such things now, since there is no public announcement from the community of any AOSP release based on Oreo yet, even.
Click to expand...
Click to collapse
Did you perhaps had some time to look in to this ?
If they used this api in the latest pie beta ?
i read something om miui forums that they used the biometrics API in miui 10 pie versions from other phones.
i'm lacking the knowledge to look in to this myself :/
frietketeltje said:
Did you perhaps had some time to look in to this ?
If they used this api in the latest pie beta ?
i read something om miui forums that they used the biometrics API in miui 10 pie versions from other phones.
i'm lacking the knowledge to look in to this myself :/
Click to expand...
Click to collapse
I'm not sure where to look, to be honest. This seems more like a back-end thing that makes development easier, rather than adding new features? At least that's what I remember.
Also note that I have no interest in custom ROM's personally; I'm modding stock MIUI instead.