[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
I know that "find a clean solution for the boot jar hack" was a bit euphemistic... I think it will end in hacking build/some.mk... ;) That's why I want to wait for a continous time frame before confusing myself in a hurry... ;) And - of course - it doesn't make sense to use a callbacks-striped apk after implementing them in frameworks. libs in system/lib* works flawlessly since I've added com.oneplus.camera.

BTW: my deepest respect for reverse engineering this proprietary stuff:

...Our continuing mission: To seek out knowledge of C, to explore strange UNIX commands, and to boldly code where no one has man page 4. [ldp]

Any feedback is welcome. To help to get more information and understanding of the latest changes in gservices, it would be great if you could supply us with the context sfn failed:

Which build?

Clean or dirty flashed?

Version of gservices?

Uninstalled the shiped Magisk before installing the betam13?

Logs: logcat as well as magisk log.

What app(s) exactly fail.

GPS:

I learned much on our gps implementation and gps on android in general. First of all: the term agps seems to be used in different meanings. To avoid misunderstandings: if I use the phrase "agps" (or a-gps) I'm refering to any location data used to determin the current position, which is NOT send in the satallite's datagrams.

There are - at least - two possibilities to use additional data with android's location service:

Use accurate location mode: [sarcasm]google will care about your position data[/sarcasm]. Simplified: G keeps a table with your position and network context (i.e. gsm cells, ssids).

Some kind of wrapping. I.e.: GPSToolBox sits between the position requesting app and g's location service. If i.e. Navigon is requesting accurate position, the request goes to GPSToolBox, which aggregates the gps sat signaled position with agps data. The GPSTB apgs data is (at least on our devices) never injected to glocationservice, but handled by GPSTB (like a proxy or a "mqn-in-the-middle" attack - the latter metapher is better since neither glocationservice, nor Navigon know about GPSTB's actions.)

While testing my gps changes, I realized the very first time, that current gps receivers are that fast and accurate, that GPSTB increases (yes, you read that correctly) fix times by about 2s.

IMPORTANT:

Don't use GPSTB on our gps implementation - it makes things slower and does NOT give accurate time to first fix.

Currently I'm using GPSTest for testing and meassuring - any other app, that does not mess with the location stack will do. GPSTest has one uncomforabllity (I don't call this an issue): TTFF (Time To First Fix) does not show the value for the latest fix, but for the last one...

IZat:

IZat is gathering all kind of location information (SUPL, cell info, ssid and other AP info) and injects this information in the GPS (izat enabled) chipset and the calculation (which - I belive - is the reason for GPSTB slowing down time to first fix) is done in HARDWARE!

I'm still fighting to get izat to work. It's working partly - what is much better then before, but since I'm pedantic about my rom I would like to ship it fully working... On the other hand, it's good enough to clean up my work and push a build. Later today...

gps-test builds:

Don't be afraid to use a test build: I call it "test" because it is nccessary to test those builds thoroughly. "test" build does NOT!!! mean bleeding edge, pre-beta, unstable, broken or anything like that. "gps-test" will NOT rape your cat (unless your name is Schrödinger... but then agian Heisenberg will void your position... ;), eat your dog or brick your micro-wave. Promised.

Status statement accomblished.