[Android Head-Units] donaldta:
I suspect the problem is due to the program does not have the correct file name or path for his particular ROM or do not have permissions to stat the appropriate files. Generally these CPU identification apps use a combination of a cloud database and files on the running system to get an idea of the kind of processor that's contained in the system as well as its stats.

In regards to the frequency range for example, you can usually find it in the /sys/devices/system/cpu/cpu*/cpufreq directories where * is the instance of the CPU core. Generally, the information is found in the contents of cpuinfo_min_freq and cpuinfo_max_freq files respectively whose values are usually listed in Hz. As for the type of CPU, this is usually cross-referenced by a database using information from the Hardware/Revision from /proc/cpuinfo or various the ro.product.* values in the build.prop.

Most of these apps have a report back function which gathers the existing information, so that it can be manually added to the list of new identifications. I suspect the reason why the Mstar MST786	processor is being mistaken for the "Samsung Exynos 4412" is that someone else with similar values had reported back and it was the probably the closest parser match not necessarily specification match. The best way to circumvent this is to send feedback for your device when it is identified inaccurately.

You didn't by chance make copies of the /system file system when you changed models? It would be interesting to run find/diff across the files to get an idea of exactly what was changed between the options. One might even be able copy or merge the difference in order to gain functionality of both.

You're welcome glad to help, but I am sorry we were not able to find a less expensive solution.

Another person contacted me about connecting a similar unit with an active resistance circuit like in your steering wheel column. Although, in thier case the SWC was able to detect and record changes. The problem is that one of the buttons does not respond. They had thought about using a diode to segregate the current from the SWC from the live circuit but I am not sure if that would work because it would add its own resistance. But, then this morning I had an epiphany that a Field Effect Transistor might do the job by transforming the different voltage levels into resistance. Though, circuit design is not my cup of tea, so I am not exactly sure what else might be needed. I might try and bring it up in the forums at 12volt.com to see if anyone can elaborate on it.

Well, yes and no. It would depend how much you trust the decompilation. In a standard Java source code, a method marked private should only be called by its class otherwise the result are permission errors. Although, a private method could be invoked by a public method in the same class which would allow it to be called indirectly. However, a quick glance of the code shows that nothing else in the class is invoking "e", so it doesn't make sense that it is a private method; especially since it appears to be more of an action. I think it is more probable that the method is actually marked as protected but incorrectly interpreted by the decompiler as private. It would make a little more sense since the TWService class is a sub-class of Service.

I hate to join in the people asking, "why not?" so I'm going to point out that it doesn't matter if you source the product from eBay, Aliexpress, or Alibaba for that matter. You should exercise caveat emptor against the individual reseller not against the website site itself. Regardless if you purchase from either places, there is an individual reseller whom is using those website as their own "e-store front". Of course, the irony would be that you purchase it from the same reseller but using different listing from different sites. Although, I got to admit that eBay's Buyer Protection policy seems a bit more elaborate than Aliexpress.