Related
Please start a new thread when you put out a new version of your rom.
By the time the second version comes out for the really good roms it's impossible to follow all the issues as there can be upwards of 1000 posts in the thread. Starting at the back doesn't help because of all the "how's your battery life?" posts. Then again, maybe that's the problem.
Anyway, I REALLY appreciate the work you guys do on these roms and kernels. I just wish it were easier to follow the flow of development.
Thanks for listening.
<flame retardant shield UP>
+1 .... i am with you !!!
+1 . Yeah it so annoying to go through thousands of old threads...
Moved to general
Moved? Do the people I'm talking to ever look in "general?"
I support this all the way people always tell everyone to use search but you barely ever get what your looking for..
michaelh99 said:
Please start a new thread when you put out a new version of your rom.
By the time the second version comes out for the really good roms it's impossible to follow all the issues as there can be upwards of 1000 posts in the thread. Starting at the back doesn't help because of all the "how's your battery life?" posts. Then again, maybe that's the problem.
Anyway, I REALLY appreciate the work you guys do on these roms and kernels. I just wish it were easier to follow the flow of development.
Thanks for listening.
<flame retardant shield UP>
Click to expand...
Click to collapse
+100000000
Great suggestion. totally agree.
michaelh99 said:
Moved? Do the people I'm talking to ever look in "general?"
Click to expand...
Click to collapse
Well it doesn't have anything to do with developing..
Although you do make a pretty good point, it is a LOT easier just to update the thread with a new download link & change log.
It would also cut down on a lot of clutter in that section.
If you are running an older version of what that dev posted, you shouldn't post bugs unless it didn't say it was fixed in the newest version of what they posted.
Master™ said:
Well it doesn't have anything to do with developing..
Although you do make a pretty good point, it is a LOT easier just to update the thread with a new download link & change log.
It would also cut down on a lot of clutter in that section.
If you are running an older version of what that dev posted, you shouldn't post bugs unless it didn't say it was fixed in the newest version of what they posted.
Click to expand...
Click to collapse
Master, your thread specifically is almost impossible to follow because of the almost 10,000 posts in it.
The easy fix to your update example above:
1) go to post for last release
2) hit edit
3) Ctrl-A to select all and Ctrl-C to copy
4) Hit Cancel
5) Open new thread and Ctrl-V to paste
6) edit pasted text and hit preview
7) review the post and make corrections as needed
8) hit submit and wait for the flood
T313C0mun1s7 said:
Master, your thread specifically is almost impossible to follow because of the almost 10,000 posts in it.
The easy fix to your update example above:
1) go to post for last release
2) hit edit
3) Ctrl-A to select all and Ctrl-C to copy
4) Hit Cancel
5) Open new thread and Ctrl-V to paste
6) edit pasted text and hit preview
7) review the post and make corrections as needed
8) hit submit and wait for the flood
Click to expand...
Click to collapse
9. Delete the old thread.
I think it's more of a "Let's see whose thread can get the mot posts" type of thing. Because it actually makes little to no sense to update a thread from months ago that is full of non-existent issues and then ask people to search through that thread as if the answer is supposed to jump out at them. Luckily I have given up on trying to read threads.
kangxi said:
9. Delete the old thread.
I think it's more of a "Let's see whose thread can get the mot posts" type of thing. Because it actually makes little to no sense to update a thread from months ago that is full of non-existent issues and then ask people to search through that thread as if the answer is supposed to jump out at them. Luckily I have given up on trying to read threads.
Click to expand...
Click to collapse
Well first, you cannot delete your own threads nor close them.
There is a search button in the threads for a reason also..
I guess it could be a thing to get people into saying what version they are on when they report a bug/ask a question..
Just a thought
I have to say I kinda agree with the OP, although obviously from your point of view its just making work.
I run your Axura 2.1 ROM Master, and was feeling a little lag from it here and there. I was looking for one piece of information... "can I use OCLF with this ROM"... had bad experiences with Voodoo in the past.
Man, it was no mean feat to find this out. Eventually, I put the new Voodoo kernel on my phone and its running flawlessly (utterly love this ROM by the way man. Seriously. Better than anything out there by a royal mile), but it was a hugely frustrating process to figure out whether I had any other options. To get a definitive answer. Just to find something simple.
I've often asked people direct questions in PM, and got no response, or at least an unhelpful one. As a technical guy, but not a developer, any questions I have are usually pretty specific, and not newbie in nature, and finding the answer is a massive problem. One of the biggest hurdles to this is 1000+ post threads.
Sent from my SGH-T959 using XDA App
Master™ said:
Well first, you cannot delete your own threads nor close them.
There is a search button in the threads for a reason also..
I guess it could be a thing to get people into saying what version they are on when they report a bug/ask a question..
Just a thought
Click to expand...
Click to collapse
Personally I think the old threads should remain anyhow. They help to keep the versions separate, not everyone upgrades right away. People should post in the correct thread for their version, but right not this is not possible.
Also, the old, dead thread clean up is not the responsibility of the OP, but of the forum admin. I have owned and run many forums. I have used ikonboard, vBulletin, Invision Power Board, MyBB, Phorum, phpBB, and my favorite Simple Machines Forum. All of them have in the administrative back end the option to cleanup old dead threads with no posts with a set time frame.
Problem is rom gets updated, 300 posts of "OMG Thank You, flashing soon!!!!"
They don't care.. The only thing they care about is getting donations. Higher post conts = more attention = more donations. In summary: they do not care
Sent from my SGH-T959 using XDA App
grennis said:
They don't care.. The only thing they care about is getting donations. Higher post conts = more attention = more donations. In summary: they do not care
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
Sorry, gotta call BS on this one. Based on recent events I can guess that you are speaking at least generally if not specifically to Master, and he already addressed (IN THIS VERY THREAD) his thoughts both for and against. In fact so far he has been the ONLY developer to come forward and state he would be willing to do this.
Your statement does not contribute in any way to the discussion at hand, and I personally to not appreciate anyone that posts in running threads just to flamebait and be defamatory. Please check yourself.
I think an easier and better solution exists.
The problem for us the users is that we cannot find which posts relate to which rom version, correct?
The problem for developers if we choose to open a new thread for every release is to follow all 20 threads.
An easy solution would be to have one thread for the rom as it is now, BUT with every update of the rom (and the first page) the developer can add another post with update details at the end of his thread (basically a simple post reply) and put a link to it on the first page in the change log.
This way people viewing the change log will have links to the parts of the thread that discuss that update, while developers won't have 20 threads to maintain.
Sent from my Nexus One using XDA App
Whether you are following 20 threads or the same number of posts in 1 thread the work is the same because you have to reply either way. Also, all versions in 1 thread plus people still using old versions leads to confusion, and confusion equals having to clarify which ultimately means more posts. If you subscribe to the threads and use proper subjects for the thread you should get an e-mail that not only tells you there was a reply, but to which thread version and you can prioritize your replies, ie. Current version I will answer that now, 3 versions back and he can wait until I am done with what I am working on or else he can upgrade. Also since the older threads will get posted to less frequently the chance of multiple posts after the e-mail is less, so if the question is something that was fixed in a newer version you can decide it is not even worth your time to reply. As a developer you can not do that now because there may be many replies after the one that triggered your subscription e-mail that you will not see until you visit the forum.
Trust me, I have run a BUNCH of forums, and 1 thread per version is a better idea for many reasons you have not even thought of yet. If you fully think it out you will realize that it is actually easier to keep track of the 2 or 3 most resent threads people actually pay attention to then try to track the last 2 or 3 versions in 1 thread.
I've run a few big forums too so I do know what im talking about.
With 95% of users upgrade to a newer version of the rom there would be no need to keep the threads for the old roms because no one will write there. But you can't delete them. So instead of having 20 threads with 20 roms, we will have 400 threads for 20 versions of those 20 roms if we follow your idea
Sent from my Nexus One using XDA App
Hello everyone.
I decided to open this thread to help developers to complete the work on our beautiful HD2.
If this thread does not respect the rules, I apologize, and please close it immediately.
The remaining problems are:
1. WAKE UP LAG (video of the problem by ausdim)
2. G-SENSOR FREEZE
RULES OF THIS THREAD:
1) POST ONLY IF YOU WANT TO MAKE DONATIONS OR IF YOU ARE DEVELOPERS THAT ARE WORKING ON THESE PROBLEMS.
2) ALL THAT YOU WANT TO MAKE A DONATION WILL 'WRITE:
User Nickname - Donation
AND WHEN THE WORK WILL BE FINISHED, YOU CAN DECIDE IF YOU WANT TO MAKE A DONATION TO ONE DEVELOPER OR TO DIVIDE IT FOR ALL DEVELOPERS.
3) THE DEVELOPER WILL WRITE ALL THAT CONCERNS THE STATUS OF DEVELOPMENT OF THEIR WORK
4) THE DEVELOPER WILL RECEIVE DONATIONS AT THE END OF THE WORK. THEY PROVIDE ME THE INFORMATION ON WHICH WE CAN MAKE DONATIONS. THE INFORMATION WILL BE PUBLISHED IN THE FIRST POST AT THE END OF THE WORK.
5)I HAVEN'T ANY RESPONSIBILITIES IF THE DONORS GO BACK ON THEIR PROMISE DONATIONS
Click to expand...
Click to collapse
In the first post insert the solution of these problems and the way to make donations to the single developer.
In the second post I will insert the username and the amount that each user has decided to donate.
In the third post will insert the nickname of the developers, and what they are working.
In the fourth post there will be useful information to developers.
If this thread does not respect the rules of the forum please close it.
MOD EDIT: These sort of "bounty threads" rarely (if ever) end satisfactorily for all parties. Devs here are aware of the issue and I'm sure are working to fix it. If you're feeling generous once that happens, please donate to that dev(s) who's diligent work corrects the issues. Thanks for your cooperation.
MOD EDIT 2: Thread reopened as I've been informed that these types of threads are permitted. Please take my previous edit as a warning, however. I'm sorry for any confusion. My apologies. Thread reopened. ~overground
DONATIONS:
5€
20€
10€
5€ + 5€
10€
10 $
30$
5€
5€
10€
15€
20euros for G-Sensor correct fix
Developers:
Informations to developers:
1. In this thread seems that it is founded the cause of the WAKE UP LAG ISSUE: NAND Builds: 2sec Wakeup LAG
2. Additional compiled info...by deckoff:
deckoff said:
Some useful info for any developers stopping by(hopefully)
All of these is taken from this threat
The general assumption is that the problem is hardware related, most probably the LCD used, HTC uses at least two different manufactures for LCD.
Reasons to believe it
1. The lag appears in every build this user stating the same+ here+ many others stating the same fact...
2. This user states that two phones with identical software post different results. One has the issue and one does not
3. This user gets the lag after having his LCD replaced.This post makes me believe the main reason is the LCD. The fact that the LCD is one of the few things that differs from Desire hardware, too...
4. This user claims that HTC uses LCD from at least two different sources. He also tries the same software - different hardware test...
5. The bug might have some connection with G-sensor???
Some useful info about fixing it hopefully:
1. HD2 has the same LCD as Evo 4g.
2. This user states that the only build that works for him is EVO 4G one
3. logcat log form an user
4.CPU governor changes things slightly
5. dmesg log from another user
6. Yet another log
Click to expand...
Click to collapse
3. Here, there is a solution for wakeup lag designed by arkatis, but we need the help of developers to implement it.
Let the party begin!!!!!!!!!!!!!!
I will donate 20 Euro if it's fixed!
I hope someone will see this!
And €10 from me! Really hope a fix comes along!
5E from me...
At least 10eur from me in case that the payment option is not just paypal.
Cant use it from Serbia...
10 usd from me
Edit: "Thank You" given to those who offered donations
30$ for all
arkatis said:
Can't see any devs here though!
Click to expand...
Click to collapse
Please don't write anything if it doesn't deal with donations or development.
Need more patience.
Additional compiled info...
Some useful info for any developers stopping by(hopefully)
All of these is taken from this threat
The general assumption is that the problem is hardware related, most probably the LCD used, HTC uses at least two different manufactures for LCD.
Reasons to believe it
1. The lag appears in every build this user stating the same+ here+ many others stating the same fact...
2. This user states that two phones with identical software post different results. One has the issue and one does not
3.This user gets the lag after having his LCD replaced.This post makes me believe the main reason is the LCD. The fact that the LCD is one of the few things that differs from Desire hardware, too...
4. This user claims that HTC uses LCD from at least two different sources. He also tries the same software - different hardware test...
5. The bug might have some connection with G-sensor???
Some useful info about fixing it hopefully:
1. HD2 has the same LCD as Evo 4g.
2. This user states that the only build that works for him is EVO 4G one
3.logcat log form an user
4.CPU governor changes things slightly
5.dmesg log from another user
6. Yet another log
May I suggest you add stronger GPS signal/locking to the list!
deckoff said:
Some useful info for any developers stopping by(hopefully)
All of these is taken from this threat
The general assumption is that the problem is hardware related, most probably the LCD used, HTC uses at least two different manufactures for LCD.
Reasons to believe it
1. The lag appears in every build this user stating the same+ here+ many others stating the same fact...
2. This user states that two phones with identical software post different results. One has the issue and one does not
3.This user gets the lag after having his LCD replaced.This post makes me believe the main reason is the LCD. The fact that the LCD is one of the few things that differs from Desire hardware, too...
4. This user claims that HTC uses LCD from at least two different sources. He also tries the same software - different hardware test...
5. The bug might have some connection with G-sensor???
Some useful info about fixing it hopefully:
1. HD2 has the same LCD as Evo 4g.
2. This user states that the only build that works for him is EVO 4G one
3.logcat log form an user
4.CPU governor changes things slightly
5.dmesg log from another user
6. Yet another log
Click to expand...
Click to collapse
thanks...I insert your post in 3rd post.
poingdk said:
May I suggest you add stronger GPS signal/locking to the list!
Click to expand...
Click to collapse
I'm sorry but, in my opinion, this problem is less important than the other two.
poingdk said:
May I suggest you add stronger GPS signal/locking to the list!
Click to expand...
Click to collapse
I have a link in my signature, to a FAQ, there is huge amount of info regarding GPS lock... Did you read it, does nothing from there helps you.
Also I think we should stick to one goal at a time.... That might keep things more focused...
deckoff said:
I have a link in my signature, to a FAQ, there is huge amount of info regarding GPS lock... Did you read it, does nothing from there helps you.
Also I think we should stick to one goal at a time.... That might keep things more focused...
Click to expand...
Click to collapse
Thanks for the link!
But yes I have tried and tweaked as described!
GpsStatus combined with the pool solution surely does help a great deal!
Sometimes it still takes quite a long time though. In WinMO it was freaking fast with QuickGPS. Seem a bit strange that it doesn't work just as smooth in Android!
My theory is that signalstrenght somehow is a bit weaker in Android ??
Another theory is, as many other has pointed out, that maybe the A gps part can't write the data to the GPS as well as WinMO does ?? (Driver issue ??)
Kinda annoying, but sure as hell something I can and will live with. Android rocks compared to WinMo!
Lag is kernel related most probably
No lag on my device, it did during the first days of sdcard builds
device is EU Virgin mobile UK.
Hope the devs will, in their own free time, find a work around on this.
jigners said:
No lag on my device, it did during the first days of sdcard builds
device is EU Virgin mobile UK.
Hope the devs will, in their own free time, find a work around on this.
Click to expand...
Click to collapse
Is there a really way to contact the developers? Because, if they don't know the problem, it is useless to keep talking...
erestor6 said:
Is there a really way to contact the developers? Because, if they don't know the problem, it is useless to keep talking...
Click to expand...
Click to collapse
+1 If you pm them they will not reply to you!
We have to speak with an Admin guys!
Hello.
After doing a quite a bit of research I found a group that is currently making it possible to use all 8 cores at the same time. I may have said that simply enough however this is quite a feat what they are doing.
I first found out through another thread on this forum.
http://forum.xda-developers.com/showthread.php?t=2191850
In the last section of the OP, he speaks of this group and this particular agenda. I am very tech savy however I am clearly stating that this is beyond me when dealing with kernels. Which is why I come to you. This group has made a public release of a kernel build that will enable all 8 cores.
http://www.linaro.org/downloads/
-Under Kernel(Linux-Linaro presumably)
As this isn't my field of expertise, I am requesting, in lamens terms, how to implement the activation of all 8 cores.
I thank you for your time.
Sincerely,
Sincereless
I've already been working on this and have ported MCPM parts over over a month ago - It's still inherently not possible due to hardware and the CCI. I mention this in the big bold red part in the very thread you link.
From what I understood in your OP. You explained it as if it's only a software limitation. I took 3 rereads to understand this, which is clearly outside my field of expertise.
So your thread explains what could happen if it was just the software that needed tweaking, however it's the hardware that needed fixed first. Then my question to you is what is the Linaro group working on? Are they tackling this issue for when a product comes out that only needs the software of the big-little cpu redesigned?
Could you give me a simple step by step list of the problems that would need to be addressed both hardware and software? I'm very interesting in the development of this.
This thread was a mistake and has been marked to be deleted. Please find actual release thread here: http://forum.xda-developers.com/kindle-fire-hd/7-development/rom-bliss-rom-6-4-team-bliss-t3400567
Reserved
This thread was a mistake and has been marked to be deleted. Please find actual release thread here: http://forum.xda-developers.com/kindle-fire-hd/7-development/rom-bliss-rom-6-4-team-bliss-t3400567
Reserved
This thread was a mistake and has been marked to be deleted. Please find actual release thread here: http://forum.xda-developers.com/kindle-fire-hd/7-development/rom-bliss-rom-6-4-team-bliss-t3400567
electrikjesus said:
GUIDE, FAQ and Useful Links
Much of what follows applies to many ROMs. If you have suggestions for things to be added to this guide or find any errors then please let me know.
Purpose and Rules of XDA
XDA is a development site. It is for learning and sharing. It is not here to "provide" apps or support to users. Most of the people that develop or help or support do so in their free time. No one "owes" you anything. You are not "entitled" to anything. Those that help others, are polite and try to help themselves will be more likely receive helpful and polite assistance.
Rule number one of XDA is : Search
Other rules include:
Be respectful
Be tolerant
Be helpful
Don't be an ass
Q&A or Dev Thread?
There is a separate development thread and Q&A/Discussion thread. Right now, I am happy for you to report all issues in the development thread.
But as it is a development thread, you should provide logs where ever possible and only report bugs if you have clean flashed. Telling others there may be an issue if you dirty flash is acceptable but please word it as such not a bug.
A little banter is accepted in the development thread, but please don't turn the thread into a chat room. Let's keep it fun but not so long nobody can be bothered to read, otherwise I'll have to revert to using the Q&A.
The Q&A is still there and available and is more "free".
Flashing
You should clean install for best results. If you "dirty flash" then at least wipe cache and dalvik/ART and you MUST provide logs with any issues.
Clean v Dirty Flash
There are a number of interpretations of clean flash. In recovery you should factory reset or wip everything except internal storage. This will wipe your apps and most app settings.
Whilst there are ways of backing up your settings they are not recommended because they can cause issues when there are changes to the ROM which affect how settings are stored or recorded. Do not restore system data: this often leads to forced closes and constant error messages.
You can use a backup app like Titanium Backup or Parcel. Sometimes restored apps can cause issues, and it is better and cleaner to re-download them, although not everyone has the time or inclination to do this.
If you do not wipe as per above, then you are dirty flashing. This is quicker and often works. But because things are left behind from the previous flash this can result in weird issues. When you dirty flash you really should wipe cache and dalvik/ART, so that there aren't residual
Reporting Issues
Before Reporting Issues
If you have issues with your new flashed system there are a few things to do before you report them.
First, if you have dirty flashed then try a clean flash to see if the issue remains - many issues are cleared this way. Also, it is very difficult to pin-point certain issues after a dirty flash.
Also, if you have Xposed installed then remove that before reporting. This is because Xposed can change things deep within the OS and make things behave differently, which in turn makes it very difficult to troubleshoot and resolve issues. This is Xposed hate - many devs require this and will not offer any support if Xposed is installed.
Reboot. It's surprising how many issues can be resolved by this simple step. Especially if an app is misbehaving or using a lot of battery.
How to Report An Issue
The biggest bugbear of those trying to help with issues is when they are not properly reported and require to have the same questions answered over and over. The circumstances may require different information, but here are a few common items to consider posting:
Version. Often people miss this and are reporting something that was solved days or weeks ago. Others say "latest" when it may not be. Quote the version number and/or build date.
Firmware. Again, quote the date or source.
GApps. The GApps version can affect which version of Google Play Services and PlayStore, amongst others that are used. Whilst often GApps can be "out of date" without any issue, when there is a lot of development by CM this can be very relevant.
Whether you clean or dirty flashed.
A log. Necessary if you dirty flashed, very useful even if you clean flashed. See below for how to do this.
How to replicate the issue. The more specific about how the issue arises and when, the more likely you are to get a quick resolution. If no one can replicate the issue it is unlikely they can resolve the issue.
How to Take a Log
This is an excellent guide.
Some kernels have their own log/bug report option to make things easier.
Useful Links
Google and the XDA search bar are your friends.
Whatever you want to ask or find, it's probaly already there. This is why you often see replies just saying "Search!"
XDA: RULES - MOD HELP - SUMMED UP 1 - SUMMED UP 2 - BEST WAY TO GET A LOG
Frequently Asked Questions
No one answered my question.
Maybe no one has read it yet - you may need to give it time. Maybe no one knows the answer yet. Have you already tried to solve the issue? Were you polite? Did you give enough information? There is no need to keep bumping your post.
Which folder does the OTA file get downloaded to? Is it the full file or just the incremental update? Are there nightlies?
/sdcard/Download and it's the full file. They aren't nightly but they are normally very frequent.
Does BlissPop support Layers / RRO?
No. It has the CM theme engine.
Which kernel is best for....?
Stock is really quite good, so I'm not going to suggest any others, as there aren't many now and are easy to find on XDA. So much depends on you: your setup, apps, usage, signal. The list goes on. The real best way to find out is try them for yourself; give each one a few days to settle and you can observe battery usage, smoothness, speed, tweakability etc. But there is no Holy Grail kernel - one that gives the best of everything for everybody. "Performance" and "battery" aren't mutually exclusive, but most kernels are biased towards one or the other. Kernel governors and hotplugs also have an effect. If you are interested in a kernel, read some of the kernel thread.
One last point. When there are changes from CM the date and commits of a kernel can be important so the kernel and ROM aren't out of sync.
How is Battery Life
This often gets asked, but there is no clear answer that suits everyone. So lets start of by saying the team finds battery life to be very good.
There are however many things affecting battery life. Your apps, settings and signal all have a big effect. As does how often your apps are updating and whether over wifi or mobile data. Additionally, which kernel and it's settings also have an effect. As does screen brightness. Certain social and messaging apps can have a huge drain. How often you flash a new ROM has a big effect too. Ideally, from a battery life perspective, you should allow everything to settle and go through a couple of charge cycles. With the frequency of BlissPop updates I have never achieved this!
So every user will have different battery life and typical screen on time. Make sure when doing comparisons you really do it on a like for like basis.
If you want to investigate battery usage, consider apps like Wakelock Detector (WLD) and Better Battery Stats (BBS) as well as GSAM Battery Monitor. These will often pinpoint where battery is being consumed and what is waking your device. Quite often you will see an app misbehaving which can often be resolved with a simple reboot.
?
?
Click to expand...
Click to collapse
Wow! It's even official! This thread should be in 7" KINDLE FIRE HD ANDROID DEVELOPMENT section, by the way. Thanks man. I'll try it soon.
alexander_32 said:
Wow! It's even official! This thread should be in 7" KINDLE FIRE HD ANDROID DEVELOPMENT section, by the way. Thanks man. I'll try it soon.
Click to expand...
Click to collapse
I just moved it there, Thanks!
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.