Progress

[xen0n]

Basic functionalities

• [x] graphics
  • [x] surfaceflinger
  • [x] video
  • WONTFIX: drm (how can I even test that?)
• [x] backlight
• [x] audio
• [x] codecs
• [x] wifi
• [x] bluetooth
• [x] ril
• [x] camera
• [x] sensors
  • [x] gps
  • [x] accelerometer/etc.

    Further steps

• re-enable SELinux -- will track in separate issue; even stock Flyme hasn't got SELinux right (booting up Permissive), so I wouldn't pursue it for now.

[xen0n]

Backlight considered working as of commit 7033411.

[xen0n]

OpenMAX codecs working as of xen0n/android_frameworks_av_mtk@08ca029 and xen0n/android_vendor_meizu_arale@4cdc9e7.

[xen0n]

Camera working as of xen0n/android_vendor_meizu_arale@400881a.

[xen0n]

Sensors working as of xen0n/android_vendor_meizu_arale@59e2cde.

[xen0n]

WiFi and Bluetooth are both fixed by xen0n/android_vendor_meizu_arale@ecf5961, both are perfectly stable now! Hoorrraaaah!

[xen0n]

9545bb8... How come they renamed the service ril-daemon... rild (mtkrild actually but nevermind...) now properly starts. A trimmed SIM card away from success...

[xen0n]

GPS finished!

Relevant commits:

• xen0n/local_manifests_arale@6651b4a
• xen0n/android_frameworks_base_mtk@2603c5f
• xen0n/android_device_meizu_arale@a5f79cf

Holy sh*t it's framework...

[xen0n]

Also RIL work is stalled, due to some mysterious Java layer incompatibilities (maybe). MTK chose to directly work on the framework code, and the resulting RIL class is a true nightmare to comprehend... telephony-common.jar from stock Flyme even won't fully decompile.

Maybe I was just missing some enlightenment? I don't know, let's just continue compiling for now...

[xen0n]

Finally...

Turns out the com.mediatek.internal.telephony.worldphone bits are essential to correct baseband selection (LTTG flavor of baseband being correctly selected on stock Flyme, compared to LWG on CM). After some grueling Java work telephony and SMS are working... let's consider this issue resolved. Remaining bugs are to be tracked in separate issues.

[xen0n]

Also according to log output Digital Restrictions Management seems to be correctly operating since none of the previously seen errors is appearing now, but I don't have access to any DRM-restricted content to experiment with (nor should I). People with such contents are welcome to test.