[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
IMPORTANT

The last two weeks I spended more time with this rom and this thread, then I can effort. In deed I take it from the sleep time: the following are mere some (sometimes general, sometimes confused) thoughts, then direct replies to the quoted postings. I use them as "topic anker"[phrase?].

(feel free to answer to a single thought without quoting thenwhole posting... ;) thanx.)

This one gaves me a good lough... phone freezing, gps broken... BUT SN WORKS... *lol* Remembers me of the joke of the guy, who gives his car to the mechanic because his car's left front light is broken. When he gets back his car, the tires, the seats and even the stearing wheel are gone. When paying the bill, he states: "Anyway, the left front light is working."...

Stability is my very first priority. I wouldn't have shiped the rom, if I would have expirienced overheating and freezes. That's exactly the reason, why I only build for devices I have my hands on.

I take this one very serious!

For bat life in general: I flash test builds so often, that it would be silly to give an oppinion on real world bat life - but I'm pretty sure, that we don't have some serve draining. Actively fixing to and hold fixes to sats (did anyone realize, that this rom the first time gets fixes on baido?) needs more energy then sending gps hardware to sleep (sic!)., but other then that, I havn't observed increased bat usage.

That's the point where - according to qcom's sales department - izat kicks in: as in silicon baced additional data using location provider izat should reduce bat usage and accuracy at thensame time.

For gps (or should I say sat hardware location, android location service, com.qualcomm.location, com.qti.location, izat hardware (nearly no documentation) and izat service and their all interaction - and on top of this - at least for me - complecated mess google comes with it's own location service) in general: this is still wip.

Working: pure gps hardware up to the android loc srv. hw uses gps, glonass and baido.

Not working but for testing purpose not completely disabled (aka partly running in the background): izat and - at least - it's dependencies regarding the devices sensors and gathering loc data from lte/ims.

ims (btw: I ended my thoughts on gps): same situation as with izat: somehow partly working...

qmi seems to have some hick ups, too... but I havn't found the time to look into.

But hey, we are using open source software, which relays on some closed source parts, because we have no source for. No open source rom user should be surprised that there will be issues of all kind when it comes to using the closed source parts.

The increasing issues with with google apps/services is also something we have to accept. (grep for gms in logcat, and you get dizzy... :( )

No matter what sales manager, ceos or other important people say, there will always be something the companies will hold back: they have to make money with their proprietary knowledge/information. Sadly, this works in our economic environment only untill this knowledge (documentation and source code) is public domain.

I would like to have a "one package flash": while digging in something (like gps for the last weeks), I often need to flash a build with only a little change in system and an other boot img. Loggers are prepared and data for selected apps are wiped. All to simulate something, I've got reported of, but havn't received logs for (SCNR). Test goes of just to gather this special three lines from logcat... 30 minute setup time... ...booting... ....just to realize, I you can't do my checks in an easy way, because root access is missing...

Since I have little preference which package grants root access, but the user's demands on what let them pass the checks for theirs individual uscases are so different and fast moving, that I belive that shiping this rom basically SN api compatible and therefore without any root package is the cleanest, most straight forward and most responsible solution. [Hmm, strange looking sentence - I hope I wrote what I mean]

On flashing:

People are different. This is also true for the state of their devices and what they understand when reading clean or dirty flash.

I take a bet that the most issues after dirty flashing (or updating Oxy for that matter) are no error in the new rom version or zip, but something an app has done formerly (btw: this app doesn't even need to be a root enabled app or to be installed anymore), or a zip with a so called fix...

I'm using my current rom setup since the second week of Feb. I do more often and much more awful things to my roms configuration as most of you can imagine. I have always either the knowledge to undo exactly all and everything (I mean really, really all) or I go back to my last backup. I never continue the dirty flash update tour, if am not 100% (I'm talking of the real, not the alternative 100) sure I've cought every change in my system (including all (again: all!) apps I've installed since it was known to work (remember: date of issue came up != date of known to work).

Sometimes I do a "semi-dirty" flash: I wipe dalvik, cache AND system (and reflash the gapps the installation was initially installed with).

At least half of the issues with clean flashes, was that people think doing factory reset prior to flashing is the same as a clean flash. Clean flash always contains wiping system (and for twrp-3.0.4-1: umounting system afterwards).

Once and for all: clean flash means wiping dalvik, system, data and cache before flashing the rom. Always remember you have to care about formware yourself, if you come from an other rom or have a version bumb in your update history.