Rom: Android Pie for S912

[RiCkLaR_atvX]

.... Though the build is not cleaned up..... Seems like there is a lot of developer left overs.... Probably would release 500mb just in some clean up.
....Seems like if I go too high I notice some slowness, but it may be that I did not go far enough for eualization of the memory parameters.

If the ROM hasn't been cleaned, that is also a problem, one key file that can needs to be adjusted is '/vendor/etc/lowmemorykiller.txt' -- from AOSP to Amlogic SDK nobody deleted the files or modified them, has a bare minimum phone profile set for a 512gb ram and 2 gb ram file that both can be deleted, leave the mentioned 'lowmemorykiller.txt' and can again use L-Speed to get the values that should be set according to your devices RAM.

Example one line changed from that txt file :=

adj=0,112,224,408,824,1000

[X92-2GB]

If the ROM hasn't been cleaned, that is also a problem, one key file that can needs to be adjusted is '/vendor/etc/lowmemorykiller.txt' -- from AOSP to Amlogic SDK nobody deleted the files or modified them, has a bare minimum phone profile set for a 512gb ram and 2 gb ram file that both can be deleted, leave the mentioned 'lowmemorykiller.txt' and can again use L-Speed to get the values that should be set according to your devices RAM.

Example one line changed from that txt file :=

adj=0,112,224,408,824,1000

Thanks! 9.0 has been a journey with my phone, and a jungle with the v8a build. Will do on the vender clean up.

as for memory settings... slight improvement with your settings. But changing from 512k to 2mb does the trick. Though I found too much memory adjustment may slow some processes during initial boot. Images slow down in populating on startup.

I will update on my findings after I so the cleanup in vendor.

[X92-2GB]

I slightly adjusted lowmemorykiller.txt with only the last two entries. Went from 900 and 906 to 850 and 1000. Deleted the two others you mentioned. Will run with the settings over the weekend. I don't expect much, but it seems having done the higher memory adjustments may help, none the less.

Eventually I will remove two sdk lib folders within the /vendor/lib and /system/lib. They seem to have lib files that are not used by the build or are duplicates to what is already used in the system. Once they are cleaned up, I will move most of the vendor over to system. One build.prop is better when adjusting. Right now my vendor build.prop is only vendor related. Most of the entries are already in my system build.prop.

[RiCkLaR_atvX]

One build.prop is better when adjusting. Right now my vendor build.prop is only vendor related. Most of the entries are already in my system build.prop.

Since android-8 all your Prop.TWEAKS should be located in the 'vendor/build.prop'

[X92-2GB]

Since android-8 all your Prop.TWEAKS should be located in the 'vendor/build.prop'

Oddly the 8.0 and 9.0 phones I have a lot in the system/build.prop

I will look in my 9.0 phone, at the vendor/build.prop. maybe the newer updates did a few change up. As before I did copy the system build.prop which was held most all the system properties, at the time.

Maybe some vendors preferred to use the system/build.prop, donno?

[RiCkLaR_atvX]

Oddly the 8.0 and 9.0 phones I have a lot in the system/build.prop
I will look in my 9.0 phone, at the vendor/build.prop. maybe the newer updates did a few change up. As before I did copy the system build.prop which was held most all the system properties, at the time.
Maybe some vendors preferred to use the system/build.prop, donno?

Well System-build.prop is old way, with Google implementing GSI they want system.prop to be basic/minimal as possible, so a GSI flash won't affect the core functionality.

Just looked at a Andriod-11 (R) system.prop and it only has 2 "additional_build_properties" --

[X92-2GB]

Well System-build.prop is old way, with Google implementing GSI they want system.prop to be basic/minimal as possible, so a GSI flash won't affect the core functionality.

Just looked at a Andriod-11 (R) system.prop and it only has 2 "additional_build_properties" --

Ok... just looked over my 9.0 phone. Not a build.propto be found outside of /system/build.prop. though them buggers renamed some good lib files for decoder. Unless the system reads them with their modified extendions, I am SOL on using them. Audiosphere, flac, wmv,wma, and a few other high definition audio sources seem locked out by their renamed file convention. Though I am using My Player Pro for what the 9.0 phone lacks on codec. Geeze, my cheap tablet does flac and wma, wmv, and h264 10bit.

The h96 pro box only needs a few codecs, though mx player pro does come in useful time to time.

[ReaperMan]

@minhthien0711,
I'm not a Dev or programmer..
If your WiFi is not referenced in the kernel (I think?) you are possibly out of luck.
What is the model (how old) is your China Box?

[X92-2GB]

I think I found the odd reboot issues on wake up, after deep sleep mode with android 9 firmwares. I did some tests with HDMI mute and scan timings. Even though I was able to speed up or slow down my TV HDMI connectivity handshake settings, no changes to resolve wake rebooting.

From seeing that my reboots are not related to system freezing after wake, as they seem to be as if the system was given the reboot command, soon after wake. After watching my thumb drive light during wake up, I noticed the USB and micro SD card are hit by the system, soon as the system wakes. I think the issues may be a timing issue or a lack of voltage to keep cache from being corrupted in sleep mode once the system goes into deep sleep.

since the box is always powered and no battery is used, I decided to disable deep sleep by disabling each app from being monitored and forced closed by the system. A number of system apps are set to go into deep sleep by default. Being that none of the 9.0 firmwares are built for tv boxes, over looking what the system is doing to close apps, may effect how well the system performs with memory devices connected. I think if you disable all the system apps from deep sleep should make a difference.

I have removed all my plugged in memory devices (1 thumb drive and 1 sd card) and will test further through the weekend.

I did do a sysctl > dump.txt to compare with othere 9.0 systems that have good sleep wake functions to find any differences with storage settings. I have a feeling the storage settings are not compatible with the the older and slower devices I used previously with 7.1.2 firmware.

I have noticed better wake and boot ups on short use. The problem usually shows soon after deep sleep occurs. I may have to add more delay time to the storage initialization. I also have a feeling voltage to the memory may need a .05v boost.

[X92-2GB]

Seems that the external memory devices cause the system to reboot, probably to incompatible timing with older devices. The system when woke expects cache to properly sync with memory, and will cause a system reboot, instead of hard crash.

now that I have no external memory cards installed, wake from sleep function works as it should. As for deep sleep, it's not needed, but I recommend disabling the system apps, since they are hardly changed and have no effect on power consumption, since the device is plugged in to power.

HDMI CEC functions as it should. Power on from tv wakes box, power off from tv puts box to sleep. 10 minutes after sleep, box goes into deep sleep, requiring tv or ir remote to wake. Box requires ir remote to power on. I think dts EID enabled may allow tv to wake box from power off. There is also two settings to enable HDMI input, in which one will keep the tv on if hdmi is connected, if enabled. The other is am not sure about. So I will be playing with three options in the build.prop later on. TV is used mostly for today.

now that I verified external memory timing settings need adjustment, I will dive into correcting the timing along with adjusting wifi speed. Moving from Cubic to Reno will be a plus just in its self. A simple sysctl script to run a boot will all that is needed to fix the issues I have been seeing since using v8a 9.0 firmware. Wifi is fast, but not optimized. I get 90mbps down and 5mbps up. Once I get done with tweaking, it should be stable around 110mbps down and 15mbps up. Old docsis modem won't do any better on download speeds. Lan gets 125mbps through my docsis 3.0 modem. Though most of the congestion is from Corona bandwidth throttling by providers.

[ReaperMan]

I also adjusted '/vendor/etc/lowmemorykiller.txt' and deleted the 2 extra files in Z95 mod. Will see if it makes a difference...original runs smooth in most cases.

H.D. transfer speeds are terrible. Before Pie I could get up to 20 MBs USB-2. Now typical 200-300 KBs. If I restart USB hub 2 or 3 times..max speed can reach 5 MBs.
If transfer is not top running app, transfer speed drops another 50 %. Previous speed will resume when app is main focus.

I think Pie (drivers) is using backward compatibility from USB-3 ?

[X92-2GB]

I also adjusted '/vendor/etc/lowmemorykiller.txt' and deleted the 2 extra files in Z95 mod. Will see if it makes a difference...original runs smooth in most cases.

H.D. transfer speeds are terrible. Before Pie I could get up to 20 MBs USB-2. Now typical 200-300 KBs. If I restart USB hub 2 or 3 times..max speed can reach 5 MBs.
If transfer is not top running app, transfer speed drops another 50 %. Previous speed will resume when app is main focus.

I think Pie (drivers) is using backward compatibility from USB-3 ?

we only have usb2 compatibility, so driver should handshake down to default compatibility. I see no differences in speeds with the build I am using, compared to SC ATV. Though I don't or have not used a speed test to verify speeds. Just over all use in general. Never noticed issues, until recently, though it shows up on booting, not after system has booted. I had cleared up a lot of lost files on sd card. Probably cross linked orphans from ti back up, as that is my primary use for writing to.

every thing was doing fine until this morning. I may have to do a complete clean flash once more. HDMI has started up again with cec issues. Seems that some of it may be due to mods to the system build.prop. I realized once the system stuck on home screen every thing looked as if my screen size setting had changed to 100, not the setting of 240 I use on my box. So everything was super small. I copied over a backup build.prop remembering I had removed vendor build.prop duplicates from my modded system build.prop. so no size setting was being pushed through the system. Donno, if I had forgotten to place screen size property on the build.prop.

For what ever reason every other boot seems not quite the same. Sometimes my quick shut down functions, sometimes a wee delay in boot animation just before android logo. I am thinking the system cache, or kernal Sio paramenters may be off. I may use a kernal tweaking app for adjusting more than what I have been on build.prop.

I remember seeing something like this way back on my old tablet using 4.4.2. I adjusted memory settings too far, and boot ups were effected.

Any way, I am done testing, until I have done a clean install, once again. This time I will do very little with any tweaks and mods.

I did get farther along, with location services. Some apps oddly enough could not detect location right. So I loaded some framework from my phone and downloaded location services app and added it to priv-apps. Also had to create a data folder for an error that would pop up soon after boot in log cat. It was not critical but missed in the configuration, some where. I like to clean up as many wee errors as I can. Though the v8a system runs pretty clean on the logs.

I haven't tested the Bluetooth APTX HD, as I have yet to obtain proper bluetooth headphones, or module for my AVR. My phone has the v7a modules.

[ReaperMan]

I agree with the different boot-up and shut-down operations not "seems" but are actually different!
Yes after several boots, Dalvik cache(?) is properly adjusted. Boot-up (timed) is regular...unless you mess with system settings...cache cleaning. Shut-down on different firmwares(Pie) vary. Most-times smooth..or untimely and seem to hang.

** I think past firmware...I had to change DPI via settings, but, also go into build.prop (forget which location) and also enter it manually to maintain a stable desktop layout. (A lot of junk files and folders left-over...but some pieces are still active. )

[X92-2GB]

I agree with the different boot-up and shut-down operations not "seems" but are actually different!
Yes after several boots, Dalvik cache(?) is properly adjusted. Boot-up (timed) is regular...unless you mess with system settings...cache cleaning. Shut-down on different firmwares(Pie) vary. Most-times smooth..or untimely and seem to hang.

** I think past firmware...I had to change DPI via settings, but, also go into build.prop (forget which location) and also enter it manually to maintain a stable desktop layout. (A lot of junk files and folders left-over...but some pieces are still active. )

Hi, I had downloaded smartpack from Github. It's Kernel Adiutor that also works on ATV. I found one issue that points to kernel settings. I changed the cpu governor to performance, and bumped up i/o scheduler ram to 384k while moving to cfq, as all other schedulers end up corrupting memory. That I learned from testing with governers, on speeding up my old tablet.

going to run it through the day before setting it at boot. If you decide to try my settings, you may find the subtle improvement nice. The app does have low memory killing functions, so you can apply what our currently using when trying it out. I try to run without having utilities to perform tweaks, but allow one like this to do it for testing. I find too many get in the way of boot processes. So you may need to check and disable any apps that may get in the way.

seeing unfavorable kernel settings, justifies my assumption that cache coruption is happening from the kernel stand point. A bit needs to be adjusted to smooth out the wrinkles.

[X92-2GB]

I got down to my final testing with tweaks, as I found most of the wee wrinkles can be fixed with build.prop, and other config files. For those who want a tool to do everything, I recommend giving smartpack from github a try. You must scroll down a lot but it has just about every feature you will ever need to be a Swiss army knife for tweaking and automation.

I did a few small tweeks with it, on load on boot settings. The wee changes I kept are setting the 1st half of the CPUs governor to performance. As for memory tweaks, I set i/o scheduler for external memory to cfq.

left z ram caching at 128. When to 384 it was nice for large files, but 128 was much smoother on lots of small files being loaded with app packages. You can see for your self on the wee tweaks. Install xfinity stream tv and start it up before applying tweaks. Reboot wait 10 minutes and apply the settings given, and load stream tv again. A noticable improvement, since that app tests both the loading of a large app and network connection for loading images. The initial loading will show real world performance. Most of the streaming apps have a delay built in for splash screen, so most likely you may not see much difference if expecting similar results. The delays with xfinity stream tv loading are real time once the stream tv logo has finished it's posting.

Set the network fragmentation to Reno, which gave me my 100mbps downloads on wifi. My provider is throttling my bandwidth during corona. I can see it with LAN much easier, as I can peak at 150mbps and quickly drop down to 100mbps.

after a few last tests with sleep mode. Around 12 or more minutes of sleep, the cache corrupts. It's nothing to do with timing or cec data, the issue is kernel and the voltage used during sleep. It may be corrected with patching a system module, as it may be the reason why the red led does not enable. Having too low of standby voltage, may corrupt cache, having triggered panic reboot. Seems like the longer the time period during, after 10 minutes of sleep, the more odd the system will boot. Example 1 hour of sleep and beyond. A minute of boot screen will happen, then the boot screen will reset for another boot attempt and boot. Sometimes effecting box functions. I had straight audio pass through, mute and volume had no effect, at one particular instance. Around 12 minutes, the boot would sit at animation screen and lock for 1 minute, then reboot. Other times within a 15 minute window of deep sleep, the reboot would do 3 attempts after boot logo init, then boot into boot animation for normal boot. All the above seems to point to cache corruption. I have done all I can do to correct timing, yet it seems to be effected by deep sleep. The longer in deep sleep the more boot up is effected and how the system functions after booting up. I recommend disabling sleep, and setting remote button to power off. I set my box to use screen saver settings, with 12 hrs before sleep. If I am away for a few days, I shut the box down.

if you have your box go into deep sleep mode, it's best to just unplug the box for a minute and then connect power.

I would use the Vietnamese v7a firmware, but it does not run all my apps, had has bugs with phone apps. Mostly because it disables a needed function within surfaceflinger. The fix for v8a firmware that does have screen flicker, is to disable surfaceflinger in developer options. At least you can enable it back for apps that require surface flinger. Something v7a firmwares cannot do because of the modification done to surfaceflinger's core functionality.

like I stated before many a time. Peacock TV is the only app that is plaguing me from full functionality with the v8a firmware.
I am sure later on it will eventually work under a new update. NBC apps are that way. It's not the first app to break on a TV box by NBC. I am not in a hurry anyway. Just letting people know what to expect.