Sorry I've been absent, but been busy with work.
It's this precise thing I noticed as well
hwgasdfasdf; a perfectly fine tablet that you can use for media consumption but when it comes to touching the Wifi connection, it suddenly stops, starts breaking and simply crashes constantly, always freezing and what not.
Concerning the NVRAM error, you said you found a solution. Care to share the file or the proccedure you did to fix that?
Thanks
I may have found a solution last night after my post. After you add a google account, immediately turn off the wifi, and go to your account settings and turn off ALL of the account syncs. I only enabled Contacts sync, and Gmail sync, and left all of the others disabled, then you can turn wifi back on, and now it doesn't randomly black screen and crash. So the issue causing the random crashes seems to be with account sync, not upgrading google play services or the play store - but I'm still skeptical that upgrading those doesn't also cause other issues.
It's complaining that it won't run play store unless I update google play services - all lies - I turned off auto updates and I haven't updated google play services, and the play store works. It's a super old version, but it still works just fine - I disabled all play store notifications - problem solved (or kludged) for now.
I will do some trepedacious testing of upgrading google play services and play store manually (over adb) to some older versions. I'm very skeptical of letting it just do whatever it wants. The tablet works absolutely fine with the old versions, and is MUCH faster than it was before, and much faster than the other one that didn't brick itself, so I don't want to "upgrade" right back into reduced performance again.
The difference in responsiveness and speed of this freshly imaged un-upgraded one compared to my other working one which is somewhat upgraded (I have auto updates turned off on that one too, but it is updated newer than the stock image) is actually shocking! The old one feels horrifically and painfully slow in comparison. And if you compared the two before, that one was a lot faster than this one, before it bricked itself. This one always had issues since upgrading it to MM / android 6 a couple of years ago.
The NVRAM issue, I have a temporary workaround for, but not exactly a fix yet. I used SPFlashTool to read back NVRAM partition from my second A10-70F which is still working and didn't suddenly zombify itself to the point where it wouldn't even turn on, and then flashed it to this one (so they both have the same wifi and BT mac addresses currently, which is less than ideal, but they're not both turned on at the same time - and usually they are not in the same physical location, but I would still prefer they had separate mac addresses). I tried changing the wifi and bt mac addresses in the image before I flashed it back, only changing the last character of both mac addresses, and I got the NVRAM ERROR = 0x10 again. There must be a checksum that needs to be updated when you change the MAC or something (or I did something wrong). That was kindof in the middle of figuring out the proper steps to flash too, so who knows what state the rest of the system was in then. I find if you don't do the imaging steps in just the right order, you end up with weird behavior - the progress bar on first boot never completes, or if you get it to complete, the wifi is super unreliable later, etc etc. It seems very touchy to end up with a stable system in the end. I'm not sure why every image doesn't "format the partition, THEN copy stuff to it", but it seems like some just copy stuff on top of what's already there, leaving some old stuff behind, then you end up with weird issues.
I also tried the "replace the file in /data/nvram/APCFG/APRDEB/[WIFI, WIFI_CUSTOM] in a root shell" method mentioned in another thread as a generic solution for mediatek devices which have this NVRAM problem, and wasn't able to change it, remove the error message, or make it permenant. If I change that file, it changes the mac address temporarily, but then I get NVRAM ERROR = 0x2 when I turn the wifi back on. On reboot, it goes back to the invalid mac address and NVRAM ERROR = 0x10. If I read back /data/nvram/APCFG/APRDEB/WIFI, it still contains my changes, but it obviously does not like them and is defaulting to the invalid mac address.
I have a replacement motherboard on the way (when I thought the issues was the EMMC memory was screwed on this one, which is clearly NOT the case - it's all software / android problems), I will be able to use that one to read back the NVRAM partition there and then I can compare the 2 working images to see what else is different other than just the MAC addresses, and this should point me to the checksum.
If you look at the file /data/nvram/APCFG/APRDEB/WIFI, it looks like the last 2 bytes are a checksum, but I couldn't find any common 16-bit checksum method that would give me that checksum for the contents of the rest of the file. There's a couple other 16-bit values that are in the middle of long stretches of 0's that also could be checksums (possibly on only parts of the file??). I think comparing to the NVRAM image from the other motherboard will be enlightening here.
I will post again when I figure out more.