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
Hello xda-devs
First of all, I need to clarify that we have nothing to do with the Legendroid ROM that was produced by RaiderX303. We named our kernel on behalf of our community forum - LegenDroid.com which was registered before LegenDroid ROM was posted.
Also, please note that we are aware of Ivan Dimkovic's Diet kernel and started this project development before it was released. We were going to terminate this project, but then decided to continue it since we are not overclocking, and are using original repository.
A little about our kernel, we are using the official Nexus One git repository which is located at android[dot]git[dot]kernel[dot]org (sorry again: ). Therefore, we will be using the 2.6.32-nexusonec tree for our kernel. Our kernel has also included the Undervolted (UV) and audio loudness fix. We have removed the most dev tools and trimmed down the kernel to its most basic, user-friendly, fast environment.
Basically, our target users are those who don't really need dev stuffs so maybe xda-developer may not really be the best place to share this piece, but who knows, someone might just be looking for it here, so here it is. The kernel was crosscompiled on GNU/Linux, SlamD64 laptop. These are the features it has:
Based on android.git.kernel.org, 2.6.32-nexusonec tree
Static/basic undervoltage
Compiled with NEON and VFPv3 extension support
Disable most of the debugging options
Disabled loopback block device
Using SLOB events controller
CBQ in network
Enable all the cpufreq modes
Enabled HIGHMEM. RAM size will be 394MB
Enabled EXT3/4 filesystem
Audio Loudness Fix
+ 8MB RAM reclaimed from Camera hack - patches by pershoot
- Disable BUG() function from kernel. This will make 'less' warnings' and decreased in kernel size too.
How-to guide, download link and other info can be obtained from our forum at legendroid[dot]com (sorry guys, not enough posts, can't post direct links). I wanted to post it here, but since we will updating it pretty often, it will be best to manage the updated link in one place
Kudos to xda-developers team. Without you guys, this was definitely not possible. Thanks for providing this mobile hacking heaven.
Not to forget, the Android sifu, cyanogen for his endless efforts, along with his kanging #teamdouche. You guys kick some serious arse in Android world.
Happy trying and feel free to feedback us with issues, bugs or anything else.
Regards,
Shahz - LegenDroid Community
No feedback guys? I'd like some testers if possible.
And I don't need donations or mobile phones like most developers ask for. I just need testers. Consider it as my learning playground, and you guys are the gurus
Important: The docs are up. The live copy can be found on http://docs.insertcoin-roms.org/ and the Git repository on https://github.com/Manko10/InsertCoin-Docs/. For information on how to participate, see the wiki.
Hi,
This thread is related to the InsertCoin ROM by baadnewz (see this thread: http://forum.xda-developers.com/showthread.php?t=1198684). Since I haven't written 10 postings yet, I can't post to that thread nor create a new one in that forum.
InsertCoin has become a quite popular ROM for the HTC Sensation. It has had 200,000 downloads yet and numbers still raise. With increasing popularity it becomes more and more difficult to get hold of information you need concerning installation, problems, modification, tweaking etc. The result is a very high number of redundant questions on the forums and confused newcomers.
The project
Thus being said, it is time to create a good and centralized knowledgebase which helps new users to dive straight into using InsertCoin, keeps the development thread cleaner and helps to push the project forward since energy can be focused more on implementing new features and fixing bugs than on answering the same questions all over again.
baadnewz attempted to launch a Wiki once, but it ceased and shut down (as well as the whole baadnewz.eu server which was the last more or less valuable resource for help outside XDA-Developers.com).
Now my idea is to create a new official InsertCoin documentation project. I talked to baadnewz and he assured it would be promoted and integrated into the official website once it comes to life. The project I'm heading for is a community-driven one. I would work for it as much as I can but I can't do it alone. I'm not experienced enough in many (especially technical areas) of InsertCoin development and Android development in general. There are many things to learn about InsertCoin. And to be honest: I also don't have the time to write all the stuff by myself. Once I had written everything, it would already be outdated. So this project is only possible if other people participate actively.
How shall the documentation be implemented?
I thought of a project hosted on GitHub. Users can fork the project, make changes and send pull requests. For infrequent submissions, we could also provide a special submission form.
A staging server would then pull the HEAD revision regularly, format it and publish it as a website.
Sounds complicated? But it isn't. Git is pretty much straightforward and also users without technical knowledge can learn it very quickly (yes, there are great graphical tools for it). And of course, the documentation would also include a noob-proof guide to contribution.
But why Git? Why not a Wiki?
A Wiki might seem to be easier, but in fact a Wiki has to be updated regularly. Patches for bugs and security holes have to be applied. Additionally, we had to fight spam. Especially when we use some well known software such as MediaWiki, spam bots would love it. That can be a lot of work.
But the main reason is portability. A Wiki is a Wiki, nothing more. Exporting the contents into other formats would be a tedious process. However, when using plain text files with a simple markup language such as Markdown, they can be exported to all formats we like. Not only can the staging server parse it to HTML, but it can also be exported to PDF, CHM files (does anybody still use these?) and many more formats.
All right, but what is to be documented?
Well, a lot. Things I have though of are
Installation
Where to get InsertCoin ROM?
Which version?
How to flash InsertCoin?
How to upgrade from previous versions?
To wipe or not to wipe (and when)?
Kernels
Which Kernels are there?
Where to get them?
What are the differences?
Advantages/disadvantages of specific Kernels
How to install a new Kernel/revert to stock?
What is a Kernel and why can't I install it via the Market? (dumb question, yes, but important to know)
Known problems
Any reported bugs still present in version X?
How do I report my own bugs?
Why does feature Y not work (and never will)?
Features
Why to choose InsertCoin?
How to submit feature requests?
Requirements
What do I need to run InsertCoin?
Which baseband version do I need?
Where do I get a new baseband version and which one to choose?
Does it work on device X, too?
Which is the oldest supported version for custom kernels?
Add-ons
Which add-ons are there?
Where to get them?
How to flash them?
What to be aware of?
How to get rid of malfunctioning add-ons?
Customization
Which themes are there?
How do I install them?
How do I revert back to the default theme?
How to set up custom boot splash and boot animation?
FAQ
Things users ask all the time
Things users might ask regularly in the future
Milestones
Any planned features for future releases?
How many ROMs to release tomorrow?
Participation
How to submit patches?
How to improve the documentation?
How to pay a round for baad?
General information
What else could be valuable information?
How do I backup and restore my data most efficiently and least time consuming for upgrades which force a full wipe?
etc.
The list goes on. It's up to us how much it'll grow. Make suggestions please. Don't hesitate!
And now you come into play!
Do you think, such a project could become a success? Do you have suggestions, ideas, criticism? Post it here. Please.
Would you like to contribute? Post an answer. You would be one of the glorious pioneers.
If I get enough positive feedback and support by people who want to contribute I will start working on the base system, set up the Git repository, write the staging software and launch the project. If not, it would have been at least worth the effort. But you would contribute and give something back to the community, wouldn't you? Sure, indeed...! ;-)
Cheers
Manko10
Do you think, such a project could become a success? Do you have suggestions, ideas, criticism? Post it here. Please.
Would you like to contribute? Post an answer. You would be one of the glorious pioneers.
Click to expand...
Click to collapse
of course it'll succeed cause it'll be much easier with plain updated steps (n00b proof )
I would like to contribute if u may allow
THIS IS AWESOME
Of course you can contribute. Everyone is pretty much welcome to do that.
For Baad and InsertCoin itself, I think it would be a perfect success. I myself have been looking for a central resource database for InsertCoin, but always resort to just searching the thread, which is not exactly the most efficient method.
I don't know much on the technical ROM-based side of things, but I am a web developer, so I'm sure I'd be able to help in the deployment of such a website. I also happen to have a vBulletin license I'm not using. If Baad wants to expand his ideas even further and have a sort of official InsertCoin forum, all to himself, I could most definitely lend a hand for that.
I'm thinking large scale here; and upon writing this, further ideas have just popped into my head, but I'll save that for later, but hey, Baad is largely-awesome.
If you happen to have an MSN or Skype, Manko, I'd love to talk to you further
i have a better idea for talking / chatting in a more centralized way: IRC
#baadnwz-roms on freenode
I don't know much on the technical ROM-based side of things, but I am a web developer
Click to expand...
Click to collapse
So am I.
I'm quite sure, baad will help us as good as he can but he is of course very busy with the ROMS. So it's better to have many guys in the project who know more about the technical stuff.
I would try to help too, if You like. If You don't need IC pro's only
We need everyone (IC pros are needed, but not only).
First of all we need people who have fun writing and maintaining (!) good and understandable documentation.
Guys
if you do this - it will be bloody FANTASTIC!
noobproof guide needed badly
Make it so. Sounds like it could become a great resource.
It will, but only if enough people participate.
why not add chatbox on the coming site, isnt much better? 24/7 we can have conversation as like me, am from the philippines, and my time is different to others
Well, the documentation would also be there 24/7. I think for live talking we should better use IRC (#baadnwz-roms on irc.freenode.net). Embedded chats on websites consume a lot of bandwidth.
lol!, i guess so, yeah, maybe irc is much better. anyways, maybe i can contribute some design for future use.
Just jeep in mind that IC is also made by baadnewz for the Desire (and the wildfire too?). I'd like to write some things for the Desire version of IC.
koenvbeek said:
Just jeep in mind that IC is also made by baadnewz for the Desire (and the wildfire too?). I'd like to write some things for the Desire version of IC.
Click to expand...
Click to collapse
yes once the project starts, desire will be there too
for wf i made 2 roms long time ago, and then i sold the phone
Ill contribute if i can I love this rom
wow... this sounds freaking awsome. i would most definately help with coding once the repositories are set up ^_^
I think it would be really beneficial for everyone especially for the folks who are new to the ROM. 600+ pages of comments are a LOT to read through!
Make it so. (with Jean Luc Picard's Voice ) Nice idea.
Would like to contribute sth, though I have a really tight schedule lately...
I've been trying to either find or if I have to develop a tf101 kernel that has a standardized /sys/.. vdd_levels interface for changing under/overvolting and also for seeing what it is set to easily.
Of the ~4 tf101 kernel developers I can find, it appears that only Blades has touched on it, but maybe not uploaded those changes to his github. I would be pretty happy to just use anyone's git as a starting point but also glad to use standard source as a starting point and add the vdd_levels to it.
To do that I'd either need a little help, or a glance at where the missing pieces that I still haven't coded go. I figure that if there are 4 known developers that there must be 10 more that are more like me and don't want to maintain or publish any binaries.
I'd be happy to keep up a github that is in working order with all the voltage + kernel code but have no interest in maintaining the kernel itself. (hey, I've seen those threads.. )
The reason I don't just go over to say, the htc incredible section and use one of the many kernels that do this and are in github already, is because this is specific to board types and that's a piece I don't know enough about yet to transfer even if I'm staring at it. I'd need to see or hear about how to do that piece.
Anyone that can help, thanks much in advance,
Mick
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.