[K3 Note Original Android Development] daniel_hk:
Oreo status

Since someone bring it up, I think I need to say something about Treble.

Treble is not a feature or something that we can have or support. The project Treble is more or less an objective which trying to make subsequent porting easier. It's a new architecture of the framework. Yes, IMHO, MTK's source were a mess and their methods were inefficient but that is not their problem. There was simply no such standard before. New devices would follow this path eventually. If the manufacturer have plan to migrate an old device to Oreo, they would have to make the adjustments. Obsolete devices like us need to adopt with what we have. That's what I'm doing now. Actually, most of the blobs can be reused with minor adjustments.

There are official materials for anyone to read. You don't need to wild guess. If anyone interested, take a look at the brief explanation here : https://source.android.com/devices/architecture/treble?hl=az

I don't want to repeatedly answer all queries and PMs so I posted the Oreo status. At this moment, I don't know if I can share/release anything yet.

The status is:

1. Audio IN: Turn out that my new approach for stream in callbacks is working. It was the Recorder app from LOS (AGAIN!:cyclops:) not working... Audio recording is OK with other apps. So Audio is working now.

2. With a few adjustments, GPS is also working now.

3. The stock charging blob "kpoc_charger" crash and the Lineage charger is not yet implemented. I use the AOSP charger with CM's images. Power off charging is working now.

So what major issues left are:

Bluetooth, Camera, video playback, and most importantly, the RIL

The last weekend, I worked on RIL again, almost forgot everything after 2 weeks though... :eek:

It's not necessarily a bad idea to start from scratch again when there seems no progress.

Up to this moment, I have tried a few different approaches, shielding the enqueue() function, rewrote my own enqueue, trying different cmd channels, rewrote with my own workflow, etc. All bring up new issues and none can fulfil all the needs yet. :(

The main problem is, when there is a new request. It should wait for the completion of the last one on the same channel before issuing. Sometimes it would cause a dead lock in the daemon/service. Still don't know how to reset from error so need a manual reset now...

I dumped all the RLOGs from stock and cm-14.1. Still can't figure out how enqueue() check the status of the cmd channels. All the functions are put inside a static blob. I just don't know why MTK is so clumsy. What black magic they are trying to hide? Using three services to handle the RIL daemon? Who on earth would like to copy such bulky and inefficient technique!? All requests functions are also inside another static blob but the AT commands are in the RLOG. Therefore rewriting the vendor library is possible but who would like to do that?

The worst scenario would be using the enqueue() directly. Which is the last thing I want to do because there would be lots of changes. A little bit comfort is all changes/patches could be done inside the interface and service. It's stupid but can still live with the new architecture...

So not much progress in RIL but I have a new idea and would try later. ;)