Related
I really don't want this to come across wrong, but I just have to say it.
Developers, I appreciate all your hard work. I understand this is all beta/test/etc. I understand it is free of cost, even to those who did donate to one dev or another. You do it because you want to, not because you have to.
But please, for the love of all that's good - keep an updated list of Known Issues!
It sucks having to read 50 pages of posts to try to figure out if a particular release is reliable or not, to find out if there's a key feature broken or buggy. What makes it worse is you can't tell when reading these threads which users are on which release, because many still post issues after they've been resolved. Others post things that aren't really "issues" but user error.
You know what your issues are, you read the threads and you fix the issues. But trying to find a decent rom to flash is very, very difficult when your OP says "No known problems" and the thread that follows show that to be very untrue. It generates a lot of extra posts with people posting things you already know about, and it generates a lot of bad will when someone flashes something only to find that there are a number of game breaking issues.
All it takes is to update a post, say #2, in your thread, with KNOWN ISSUES. Once you confirm a bug, whether you intend to fix it on your next release or not, add it to that thread. It helps you, as a dev keep track of the bug, and it helps potential downloaders know what bugs have been confirmed and make an educated decision as to whether they want to install your release.
Hiding known issues is something I don't think anyone does intentionally, but it feels that way sometimes. It feels like devs are in a popularity contest, and any admission of flaws in their particular ROM is a weakness. Well, to tell the truth, I and many others are sick of installing something that was CLAIMED to be working perfectly, only to have glaring problems that have been there for many versions.
For a civil and productive development community. Please. Be honest with your known issues. It will go a long way in building trust with the people who you're providing ROMs to, and will mean fewer posts for YOU to wade through of users reporting known issues, without having read 500 posts first.
I have a hard time believing that most devs actively hide them. Most of the time it's probably just a bit of laziness. But, yes, it would be helpful when comparing roms if the descriptions had a well-maintained list of active bugs.
Since the developers here are NOT getting paid (NO your $20 donation is not sh*t for the time it takes to make one of these roms), yes WE will have to bear the brunt of testing these roms out and letting them know what bugs if any are in them
The other issue is the people flashing these roms, coming from Eugene's to Whiskey to the ASOP roms may generate some ghosts in the software that the developers cannot duplicate themselves. I know that when I went with the TW 2.2 roms I had plenty of issues, more issues than I have had even when I was stock. Odining back to stock and reflashing the 4.2 TW fixed ALL my problems. Dont know what caused it but since I have flashed a couple of roms prior to that (no problems), I will assume there were some ghosts in my system. This is an example that unless a TW team member is holding MY phone and working on it, they may not be able to duplicate
They don't care to list them. It's beneath some of them.
Maybe AirBus should list "midair exploding engines" as a known issue too...
kponti said:
Since the developers here are NOT getting paid (NO your $20 donation is not sh*t for the time it takes to make one of these roms), yes WE will have to bear the brunt of testing these roms out and letting them know what bugs if any are in them
Click to expand...
Click to collapse
+1. Hell, at work I run a $100,000.00+ software suite and even that company won't do what the OP suggests!
If you have a problem with them stop using their roms go back to stock and see how much better theirs is even with a few bugs, not one of you has any right to complain. They do damn good work for free with some donations that do not come close to what they should be paid for it but they do not whine at all.
The problem I find is the "spammy" and useless comments average and pretentious users make which is both hard for the developer and the end user to read the threads. A dev releases a ROM and there is a guaranteed "Oh I can't wait to flash this" comment that will pop up. And there are some issues that are minor and are sometimes not related to the release that are posted and some pretentious loser who extends his ego by trying to make simple matters complicated. This forum didn't much of this problem before and I could quickly flash ROMs easily since I could clearly grasp the status on the ROM project.
I wish they would start a new thread with new releases. It's a pain to try to read through a 500 page thread, and you comments about this or that, and you have no idea which version the person is talking about. I gave up on custom roms and just using the leaked tmo 2.2, thanks for that Eugene
kponti said:
Since the developers here are NOT getting paid (NO your $20 donation is not sh*t for the time it takes to make one of these roms), yes WE will have to bear the brunt of testing these roms out and letting them know what bugs if any are in them
The other issue is the people flashing these roms, coming from Eugene's to Whiskey to the ASOP roms may generate some ghosts in the software that the developers cannot duplicate themselves. I know that when I went with the TW 2.2 roms I had plenty of issues, more issues than I have had even when I was stock. Odining back to stock and reflashing the 4.2 TW fixed ALL my problems. Dont know what caused it but since I have flashed a couple of roms prior to that (no problems), I will assume there were some ghosts in my system. This is an example that unless a TW team member is holding MY phone and working on it, they may not be able to duplicate
Click to expand...
Click to collapse
A $20 donation is not worth the risk of bricking a $550 phone just because they got "lazy" and didn't notify donators/downloaders of [a] potentially show-stopping issue.
Posted a new Thread in Dev section for the purpose of reporting issues. So if you have an issue please shoot it to me and I will post it in that thread.
Update: Here is the link for the WIKI page.
http://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S_SGH-T959#ROMs
swehes said:
Posted a new Thread in Dev section for the purpose of reporting issues. So if you have an issue please shoot it to me and I will post it in that thread.
Click to expand...
Click to collapse
You are in a heap of trouble, a lot of people don't read, and you are gonna get 1000000000000000000000000000000000000000000000 repeats of the same issue.
"OMG! MY SD CAR DONES"T MOUNT< HELP ME!11!!111"
chui101 said:
I have a hard time believing that most devs actively hide them. Most of the time it's probably just a bit of laziness. But, yes, it would be helpful when comparing roms if the descriptions had a well-maintained list of active bugs.
Click to expand...
Click to collapse
The issue here is really that a forum is not the ideal place to manage software releases. A list of bugs emerges from community testing, but there's nowhere to "post" that list of issues, or attach it to a specific release. Since there's no way for the community to add such documentation, it falls on the ROM builder, who probably has other priorities.
This kind of project could be well served by using a real software project management software solution, such as say google code, which has an issue tracker and other useful features. But XDA does already give us a better tool than the forum - the XDA wiki!
I wish people would use the XDA wiki more extensively. This would be a good place to keep updated documentation such as this, without requiring the OP to keep a forum post updated with the latest findings. All the OP needs to do is link to the wiki page, and other people can help maintain it.
OK. Looking into Google Code.
(Update) So looking into the Google Code. What Licensing agreement are the ROMs under? Is it GPL v2 or v3 or another license?
swehes said:
OK. Looking into Google Code.
(Update) So looking into the Google Code. What Licensing agreement are the ROMs under? Is it GPL v2 or v3 or another license?
Click to expand...
Click to collapse
Depends on the project. The Linux kernel is GPLv2, so any kernels fall under that license. AOSP as a whole uses both GPL and apache code.
The issue with ROMs is that unless they're AOSP derived (like cyanogenmod) they often include binaries for which the license situation is murky at best, so google code isn't really an ideal fit for a "ROM" that's only ever released as a binary.
Really I was throwing google code out there as a well known example, there are tons of other ways to track issues. There are dedicated issue tracking systems such as trac, bugzilla, etc, but they require hosting. Most of the freely available hosted services require that you're running an open source project, which isn't necessarily true for the ROMs here.
IMO a serious project could very well benefit from such tools, but just using an XDA wiki page which community members can freely update is a great first step.
So looked into the Wiki for the Vibrant and have updated some information. Let me know what you guys think. Is this the way to go?
http://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S_SGH-T959#ROMs
swehes said:
So looked into the Wiki for the Vibrant and have updated some information. Let me know what you guys think. Is this the way to go?
http://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S_SGH-T959#ROMs
Click to expand...
Click to collapse
Not to be the "Spelling Nazi", and I am not even sure if you can change it, but it is "Kernel" not "Kernal". Also, the Dev on Team Whiskey is Sombionix, not Symbionix.
Otherwise, that looks like a great idea, and possible way of tracking things!
EDIT - I guess I could go ahead and make those tweaks, with it being a wiki and all couldn't I....
EDIT EDIT - Fixed it.
Stargazer3777 said:
Not to be the "Spelling Nazi", and I am not even sure if you can change it, but it is "Kernel" not "Kernal". Also, the Dev on Team Whiskey is Sombionix, not Symbionix.
Otherwise, that looks like a great idea, and possible way of tracking things!
EDIT - I guess I could go ahead and make those tweaks, with it being a wiki and all couldn't I....
EDIT EDIT - Fixed it.
Click to expand...
Click to collapse
Thanks. On both accounts.
Maybe this should be a post to Microsoft
To quote "there are known, unknowns and unknown, knowns and and even sometimes unknown,unknowns............but.........
Developers ----develop they do not become a bookkeeper of their development.........that is coordinating work...........good luck getting any developer in ANY Specialty to do that............. reporting bugs........
---Maybe this should be a post to Microsoft---
N8ter said:
A $20 donation is not worth the risk of bricking a $550 phone just because they got "lazy" and didn't notify donators/downloaders of [a] potentially show-stopping issue.
Click to expand...
Click to collapse
I have yet to see a REAL (completely dead) "bricked" vibrant from flashing a released Rom alone. I have seen a lot of user error cause boot loops or "soft-bricks" & HWL phones become unflashable because the end user didn't take the time to research though. As far as devs being "lazy" I dont really see that when the developer is coming here for us to tell him what else we find wrong. They are coding, you flash, you report back with a logcat. This is how development is made to my understanding. If ppl are to lazy to JUST do this then why shouldn't the developer discount long winded post or something they are not experiencing? If they know there is a bug its in the OP.
If you guys can change the interwebz & how 500 post per update are made completely useless please feel free to do so....
swehes said:
So looked into the Wiki for the Vibrant and have updated some information. Let me know what you guys think. Is this the way to go?
http://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S_SGH-T959#ROMs
Click to expand...
Click to collapse
I think it's a pretty awesome start for sure
As a matter of personal taste, I think having an individual wiki page per ROM (with the known issues and other detailed info) might be nice, although I'm not sure what the policy on new pages is with the XDA wiki.
Speaking from professional experience, the most challenging aspect of any documentation system is always convincing people to use it. It's great to compile the information, but unless ROM builders and devs post a link to the wiki in the forum threads nobody will ever see it. Having good, community based documentation is a benefit to everybody though, so hopefully people will recognize the utility of it and encourage its growth!
Hi all,
in this thread you can make it known that you're willing to test developers work in progress on your Xperia X8. Developers who need testers will then contact you by private messaging.
Please understand that some – or perhaps most – of what you will get to test is not in beta but in alfa stage of development, or somewhere on the road from alfa to beta stage. This means that it may contain many bugs, and some of them serious, making your phone freeze, reboot or just generally act weird and strange. The aim of your testing is to squash as many bugs as possible, and thereby helping in the process of making the ROM or whatever it is you're testing ready to be publically released.
If you're phone's not rooted, please don't bother posting here.
All testing is done at your own risk. If your phone is bricked, Sony Ericsson Update Service most probably can take you back to the phones original state.
This thread belongs in the development section, I know, but for obvious reasons (= i'm a n00b) i'm not allowed to post there.
And yes, I hereby sign up as a volunteering tester... i'll try anything once ;-)
Cheers,
/Bertil
So who needs to get some tests done? What dev?
Did some dev asked you to make this thread?
Its just trying everything to see what works and what doesn't.
Doesn't seem hard.
Yea, ill be a tester
Sent from my E15i using XDA App
Well, for example trofiniou seems to need help testing his alfa 10 of ICS for X8:
http://forum.xda-developers.com/showthread.php?t=1407351
And no, testing is not hard, but it helps the devs, there is no way they can find all bugs on their own.
I didn't know only devs are supposed to take initiative here, pardon me if i stepped on anyones toes.
I've opened this thread so that there can be a CLEAN thread for devs to discuss the development of a kernel mod to the Sprint userdebug firmware to allow a hybrid T-mo/Sprint ROM to be built that preserves T-Mo features such a Wi-Fi Calling and VoLTE.
If you are not a dev currently contributing to this particular effort, please refrain from posting in this thread and use the "ALL THINGS ROOT..." thread here for all other root related discussion.
See Post #2 for ORDER OF EVENTS, CURRENT STATUS AND REQUEST FOR HELP.
See Post #3 for a compiled summary of everything we know and have tried as of this moment.
Let me know if there is anything that you think I should add to this post that might help keep this process on track.
I believe this goal to be attainable but it will likely require some teamwork and collective imagination.
YOU CAN DO IT! :good:
Click to expand...
Click to collapse
ORDER OF EVENTS, CURRENT STATUS AND REQUEST FOR HELP:
1. T-Mo Note 7 ships with locked bootloader.
2. freeza manages to supply Sprint Note 7 users with a userdebug firmware that allows root access to be gained on the N930P
3. ethanscooter posts the following info in which he shares his experience that the N930P userdebug flashes normally to the N930T, allows boot and root:
Here's how you do it: Follow the EXACT SAME GUIDE FROM THE SPRINT NOTE 7 SECTION!
Click to expand...
Click to collapse
http://forum.xda-developers.com/spri...alaxy-t3447202
To get LTE to work again just add the T-Mobile APN (not that hard).
Also, you might want to freeze all the "Sprint OMADM" packages with titanium backup once you're rooted (will cause less of a hassle every time you boot. I understand the devs in the "all things root" thread are holding this from you because they want to fix WiFi calling but I think giving you root at all will tie you over for now. Also, I'm having problems downloading the gear VR apps with this so it's related to following this tutorial.
Thank you so much to the developers who made this possible for the Sprint note 7 and for everyone who brought this to the other variants (the T-Mobile note 7 was the easiest imo). It's a little funny to think that this whole time it was this easy and we could've been rooted all along. *If you really need the T-Mobile firmware rooted so you can enjoy wifi calling I've been working on something for a few hours but it's not ready.*
T-Mobile APN: https://bestmvno.com/apn-settings/t-...-apn-settings/
Click to expand...
Click to collapse
5. The loss of WI-Fi Calling and VoLTE as well as other T-Mo specific customizations (Visual Voicemail?) is identified as a major drawback of using the Sprint fw.Edit: Other issues as reported so far: Samsung Apps cannot be updated, any Bluetooth pairings that are made must be re-paired after every reboot 6. A T-Mobile engineering build is being sought to no avail as of yet. This would resolve the primary issue by allowing us to use a T-Mobile FW with the appropriate T-Mobile modifications for WiFi Calling and VoLTE. (Not sure yet what might be causing the issues with Samsung apps and Bluetooth)
7. In the absence of a Tmo eng boot, several devs are organizing to find a solution. The current idea is to dd a modded kernel after flashing the Sprint fw which would (hypothetically) remove the validation checks that prevent flashing modified images. Then build a deodexed T-Mobile build with the modded kernel and su included.
Progress has been somewhat limited up until now. Partially because most devs have been working quietly in their own silos and communicating ideas and knowledge has been a challenge with the previous threads becoming dominated by chatter rather than the facts as they have and are being discovered.
The other hindrance has been that many devs who are keen to work on this issue are without a device such as Rx8Driver and Chainfire.
ATTENTION:
ANYONE THAT IS NOT A DEVELOPER BUT IS LOOKING TO CONTRIBUTE TO THIS EFFORT, PLEASE DONATE TO THE TWO DEVS MENTIONED ABOVE SO THAT THEY CAN HAVE A DEVICE WITH WHICH TO WORK. ALSO, SINCE I KNOW YOU ARE ALL EAGERLY POURING OVER THESE THREADS, KEEP AN EYE OUT FOR OTHER DEVS INTERESTED IN HELPING THAT MAY NEED A DEVICE AND TRY TO HELP THEM GET THEIR HANDS ON ONE.
ANOTHER OTHER WAY TO CONTRIBUTE WOULD, OF COURSE, BE TESTING. BE WARNED THAT NO ONE HERE AT XDA ASSUMES ANY RESPONSIBILITY FOR ANY CODE THAT IS PROVIDED TO TESTERS OR USERS AND BRICKING YOUR DEVICE IS A VERY REAL POSSIBILITY.
THOSE INTERESTED IN TESTING, PLEASE START A SEPARATE THREAD IN DEV SO THAT GUINEA PIGS CAN ADD THEIR NAME TO THE LIST OF WILLING TESTERS. (PLEASE KEEP THAT THREAD SIMPLE AND TO THE POINT)
In Post #3, I will do my best to provide a straight-forward compilation of all we know and have tried as of this moment.
WHAT WE KNOW (OR AT LEAST THINK WE KNOW):
The following is the list of details that we currently know regarding the T-Mobile Samsung Galaxy Note 7 (SM-N930T) and its locked bootloader including concepts, ideas and loosely confirmed information:
FROM CHAINFIRE ON G+ (regarding SU challenges and some work-arounds):
New exploit protections
As isn't uncommon with Samsung, they've built-in some new (and arguably ineffective to actual exploits) protections directly to the kernel code, that cannot be turned off by just modifying the boot image ramdisk.
This time, they've decided to kernel panic in case a 'priviliged' process (uid or gid below or equal to 1000, so this includes root and system processes) creates another process that isn't stored in /system or rootfs. SuperSU itself does this, but so do a great many root apps. Any time this happens: immediate reboot.
I'm not going to elaborate why in my opinion this is a fairly useless protection exploit-wise, but needless to say it is fairly bothersome for the normal root user, which is probably a lot more relevant for the average reader here.
Unfortunately - unlike many of the security features developed by Google - this feature is not easily disabled by modifying initramfs (boot image ramdisk), and requires further trickery to bypass.
Maybe a better bypass is yet to by found, but for the time being, I have resorted to patching the check inside the kernel itself when the systemless SuperSU boot image is created. This prevents the user from needing a custom source-built kernel, but it's questionable how long this hex patch will work. The code that performs this patch is fairly trivial - it may keep working the rest of the Note7's lifetime, or stop working the next update.
In other words, this could end up being resource intensive to support, or not. We don't know yet. We have to wait and see what Samsung is going to do.
Bearer of bad news
We know S and Note development are generally strongly related, so we should assume to see the same 'protections' appear in the S7 sooner or later as well. This is probably the (ugly) way forward.
Workarounds
Aside from the binary/hex patch SuperSU employs (see common/hexpatch inside the ZIP), there are some more ways to get around this protection.
If you're compiling kernels from source, it seems that setting CONFIG_RKP_NS_PROT=n gets rid of these protections. You may want to disable other RKP and TIMA settings as well, but that is the one directly relating to this issue.
This protection also disables itself in recovery mode, so simply copying a boot image with these protections to the recovery partition and rebooting into recovery (which will then just launch Android) will work beautifully as well.
CF-Auto-Root
The test CFARs I have made so far for the Note7 have not worked, so since both TWRP and SuperSU ZIPs are already available for this device, I'm dropping CFAR development until I have a device in-hand.
Click to expand...
Click to collapse
FROM
STILL WORKING ON THIS - NEED TO TAKE A BREAK - FEEL FREE TO BEGIN USING THIS THREAD FOR DEV RELATED DISCUSSION ONLY
REMINDER: See above link to "ALLTHINGS ROOT..." thread for open discussion that is not directly related to solving this issue. Thanks!
Post #4
RESERVED
This is a spectacular thread with solid information and an accurate description of our intentions....i want to state that although i appreciate any efforts made that contribute to obtaining a development device I CANNOT IN GOOD FAITH MAKE ANY PROMISES OF RESULTS NOR CAN I SUPPLY A TIME FRAME SHOULD A DEVICE BECOME AVAILABLE. That said, in time I'll have the device no matter what (assuming i don't just buy an Intl F variant- although that's unlikely since $150 on the barrel head is much more palatable than $900 when i literally just had a baby 4 days ago... plus i work 50hrs a week at my regular job) so i don't want folks to think if they don't contribute I'll never get the device- in fact, honestly if I buy it myself there's even MORE likelihood it'll be a T variant- because i will...
Also, be aware the Chinese model is said to be sd820 as well, and has it's own chances of being unlocked, so when everyone's pitched in to buy myself or Chainfire a device then Samsung releases a Chinese Bootloader we can use that's unlocked and solve all our problems, i don't want a bunch of butt hurt fellow members angry with me because the necessity dried up before i could produce the intended Results. I think @freeza and a few other members who have known me around the forums these past few years will vouch that I'm a Stand Up Dude and truly intend to go as far as reverse engineering the T Bootloader to unlock it. Can I? Idk. Am i knowledgeable enough at this very moment to do it? Probably not. Can i still figure it out? I hope so. Will i brick the device? Good chance. Will i try my best and promise to research and learn whatever is necessary to make it happen? Absolutely.
Those are my terms. If you as an individual reading this don't 100% agree then keep your money in your wallet and wait until i can buy the device myself. That's as straight up as i can be. I'll make another promise. Should anyone donate but the total come up short of obtaining a device before i can on my own, i will leave all the donations in my PayPal and refund everyone's money. Only if enough is gained to buy a device will the money move from PayPal, and then it'll be one transaction to purchase the device using the account. If not enough is collected I'll refund everything that was donated...I'll also agree to prove with screenshots...
So again if you're uncomfortable then DO NOT SEND MONEY.
Thanks to all and i look forward to busting this whole Bootloader open! Or giving it one heck of a try if not!
Sent from my SM-N930F using Tapatalk
Thread moved to General
Thanks for starting something like this gentleman, but as with the bootloader thread, this is not actual development so it belongs in general. Carry on.
It's now possible to install MHA-AL00C00B203, an EMUI 5.1 early beta. For more information, see here:
Mod edit: links removed
I would like to have this thread for people who have installed it to discuss new findings in EMUI 5.1
For me so far, I've found that the battery seems to drain less, but that might be subjective.
I've noticed a definite improvement in touch response time, and time to open/switch between apps.
I haven't noticed any new features, otherwise, but they might be there somewhere.
The installation requires a lot of work which can be quite a pain, but it does seem to be stable, as I haven't had any crashing or anything so far.
Anyway, if you're running it, what do you think? How's performance for you? How's battery life? Did you find any new features? Let us know.
you there man are good in helping this community,but u use other ppls work (twrp n superuser zips )without give credit to them by upload to your own server or another cloud.well at least paid some respect for those who work on the zips.i know your service r the only way for m9 to get revive Thier device (besides c636 n al00) but at least respect other ppl works.no offence i am not saying u r service is not good its still the only way for those who doesnt wanna rebrand their phone to other region nor root their device to recover their phone from semi brick/brick.
sorry for derailing from topic.
Peace Out!!
I paid 30.77 USD to by 5 credits and have just update my mate 9 to B173 and now been downloading B203.
Paid for services are not allowed on XDA!
Thread closed!
Forum moderator,
Matt
So this thread is intended to discuss the issue of the fingerprint reader being deactivated by Realme after unlocking the bootloader. As well as possible solutions, and ways of requesting a fix from Realme.
Realme is a company that belongs to the same group as Oneplus and Oppo, namely BBK Electronics. Since it is possible to use the Fingerprint Reader on the Onplus devices after bootloader unlocking and the Oneplus 7T being quite similar in hardware to the Realme X2 Pro, it would only make sense that it should be possible to use the sensor on the X2 pro as well after unlocking.
So this seems to be more a political decision rather than a hardware limitation. :good:
Ways for you to request a fix for the issue are ideally via the Realme Forum, that is the Indian Forum (as they speak English, that more easy for most of us, than using the Chinese forum. And the Indian version being basically the same as the European version as well).
You can comment in this thread:
https://c.realme.com/in/post-details/1201215999353815040?comment=1201237884766519296
As well in this one:
https://c.realme.com/in/post-details/1199644629624946688
Additionally, you can contact Realme Europe via twitter here:
https://twitter.com/realmeeurope
As I already did, as you can see here:
https://twitter.com/realmeeurope/status/1201485228428210181
So let's make this Realme great again
The first thread seems to be deleted.
Dont know if its intended, but deleting threads with suggestions/reports of issue feels some kind of strange...
That was a thread about a recap of the introduction events. Where you could share issues and make queries.
Ther is also this thread, where a Moderator replied and wants to forward the issue:
https://c.realme.com/in/post-detail...64863306907648&subForumId=1197159778845982720
I attached a screenshot, just incase it gets deleted.
there's another one on their forum. Maybe it helps if we bump up the like/comment counter?
they can't ignore us if we can get enough noise.
https://c.realme.com/in/post-detail...64863306907648&subForumId=1197159778845982720
I think fp is disabled in color os only. May be in custom roms it will be available to use.
Sadly it seems that nobody is interested in this issue. Neither customers nor moderators/developers in the realme forums...
May be if some developers start developing a custom rom, then we will get to know. I think the unusability of fp sensor will be limited to color os after unlock. But it probably might work with custom roms
hi all , please go and hit "i am facing this issue too" button on the below link ,
I have created a bug report for the finger print sensor issue after unlocking the bootloader
https://c.realme.com/in/post-details/1200373166703116288
Well You guys should also bump your issue in the flipkart product page so that their sales will get a hit and then realme will take some steps to fix this .
I spoke to a senior developer at XDA FOR THe FINGERPRINT ISSUE AFTER BOOTLOADER UNLOCK ......HELP IS ON ITS WAY !!!!!
ENJOY GUYS !!!!!!!!!?
Lets hope for the best
bharat.bkj said:
I spoke to a senior developer at XDA FOR THe FINGERPRINT ISSUE AFTER BOOTLOADER UNLOCK ......HELP IS ON ITS WAY !!!!!
ENJOY GUYS !!!!!!!!!
Click to expand...
Click to collapse
Do you have more information?
It doesn't work on any roms (EU, India, China)?
HTCDevil said:
It doesn't work on any roms (EU, India, China)?
Click to expand...
Click to collapse
nope
I guess if it's disabled after the bootrom unlock it will have to be a fix or an custom change for the bootrom to allow the finger print
natedogg20050 said:
I guess if it's disabled after the bootrom unlock it will have to be a fix or an custom change for the bootrom to allow the finger print
Click to expand...
Click to collapse
At first we should hope there will be custom roms for this amazing device. Realme's official support seems extremely poor. And without it's support I don't know if there will be any bug solutions or custom roms...:crying:
asusgarb said:
At first we should hope there will be custom roms for this amazing device. Realme's official support seems extremely poor. And without it's support I don't know if there will be any bug solutions or custom roms...:crying:
Click to expand...
Click to collapse
They released a bootloader unlock tool and released kernel resource so I think that they're supporting custom development. But let's hope that they will fix this problem ASAP.
In the latest episode of #AskMadhav for the month, the company’s CEO, Madhav Sheth has answered some questions
The company already said that bootloader unlocking will disable fingerprint scanner, but this will be fixed in the upcoming update said the CEO. It will also release a separate flash tool in Q1 2020.
Lets wait now.
He was talking about the realme x2
sareer007 said:
In the latest episode of #AskMadhav for the month, the company’s CEO, Madhav Sheth has answered some questions
The company already said that bootloader unlocking will disable fingerprint scanner, but this will be fixed in the upcoming update said the CEO. It will also release a separate flash tool in Q1 2020.
Lets wait now.
Click to expand...
Click to collapse
Are you talking about X2 or X2 Pro device?
Thanks...