Hi,
I'm having trouble with an app which runs on some other PPC2003/WM5 machines OK, but struggles for speed on the Universal (edit: corrected machine type - put in wrong name due to total brain fade).
I've been investigating processor usage, and on the wizard "devices.exe" is using 25-30% of the processor time when the machine is completely idle. The problem app never manages to achieve more than about 40-50% processor usage - which I guess may explain why it runs slow!
Does anyone know what is using up all the processor power, and if there is anyway of disabling it. I tried removing the SIM card, and turning off WiFi, but this had no effect. Something is using a large chunk of processor time, but I can't find what.
Stuart
stuartaw said:
Hi,
I'm having trouble with an app which runs on some other PPC2003/WM5 machines OK, but struggles for speed on the Wizard.
I've been investigating processor usage, and on the wizard "devices.exe" is using 25-30% of the processor time when the machine is completely idle. The problem app never manages to achieve more than about 40-50% processor usage - which I guess may explain why it runs slow!
Does anyone know what is using up all the processor power, and if there is anyway of disabling it. I tried removing the SIM card, and turning off WiFi, but this had no effect. Something is using a large chunk of processor time, but I can't find what.
Stuart
Click to expand...
Click to collapse
Which app is that if not confidential? I can also give it a try.
It's a kind offer and it's not confidential but ... it's also not publicly available, sadly.
The problem is the Loquendo speech synthesiser, running inside our own app. Loquendo runs in it's own process so I can monitor usage separately. The problem is it cannot generate speech in real-time - and yet it can do so on lower spec-ed CE machines.
What I can't work out is what it is in the system that is gunging up the universal. Perhaps it is just a bad OS configuration by HTC - but I hoped that it might be something in particular that was loading the processor, which could be killed off.
Stuart
Hi,
I've noticed that over the course of a day, the memory consumption of the HD increases substantially... going up from about 30% to over 60% if I use it heavily. I imagine it has something to do with the different caches and the tweaks I've run (found on the forums) to increase performance. Is there a way to flush all caches so that I don't have to reset the device?
Thanks!
I'd like to know if anyone else is having this problem too.
After a fresh reboot my memory usage is about 30%. By the time Gyrator and TouchFlo restart it gets to about 40% where it stays.
However once I start using programs it will easily skyrocket to about 70%. Even if I close all the programs using taskmanager I will never recover more than about 2-3% of memory.
i use memmaid to free memory from time to time, but i we also backup a request for something that automaticly do that
shadow option for sktools made my hd to stuck so i rennounced to it
any ideeas?
now i don't know if this can affect battery performance but with computers the most efficient system is NOT the one with a lot of free ram, is the one that USES it totally... virtually having always ram at 99% would mean maximum performance... In other words: why do you want to flush the ram
This can not affect battery performance at all.
And it's totally normal to use ALL ram.
I guess you people grew up with normal Windows, that frees ram...
For example Linux has always used 99% RAM on your pc. It just uses all the free RAM as cache! So when there is more needed, it deletes some cache and allocates that RAM.
It is bad, very bad to waste memory by not using 100%. Using all memory for cache and only giving memory when it is needed is good for performance.
If you look at Vista, it does the same thing...
So it is normal behaviour, especially when you set all the caches high.
I use the SKTools application "FreeUP RAM" which does a sweep of RAM and normally saves about 5-10 mb.
BUT, I find I rarely need it as I don't seem to have any memory leak except with TomTom running.
i am not sure i can follow you
if i understand well, linux keem memory ocupied in order to fully use the whole capacity
but is not the case of windows, and sure is not the case of windows mobile
in my device, diferent processes and application take a slice of memory and does not release it even when you close them
so you end with a memory occupied 60, 70 even 80% despite the fact that you have nothing obviously running
because of that (not having enough free RAM), when you launch a new application, the HD became very slow or even stuck
correct me if i am wrong, but this is what i have noticed during the years of use of windows or windows mobile.
i am not computer literated so i might be wrong, though!
I also raise this problem here before, most expert's advise is that WM will manage memory itself, it is not necessary for us to do anything!!
I had tried to use memmaid, but it only free up 1-2M memory.
Back to the time when I use D810, if there are few MB left, I can't launch new application. Even when I close some and make free RAM left to 16+ MB, that program will still report out of memory........the only thing I can do is to soft reset.....
HD's RAM capacity is much better, but as time goes......maybe this problem will also happen!?!?
Sorry but not convinced. I agree that when in use 70-80% memory usage is not a problem. But when there are no programs running, then there is no reason to use ram.
Also on my previous wm6.1 device when you closed items in task manager it would restore ram. Sure not all of it but a good chunk of it. Heck, even on my previous HD using the task manager would free more ram.
The only thing that I can see that is different between my previous HD and this one is Tweak HD and the TouchFLO Calender. So I will try removing those first and see what happens,
Eventually, after flashing Laurentius's ROM, the problem went away almost completely. Have to say my memory usage is pretty stable now, at around 40-45% even after a day of full application and web use.
dunno personally i'd love to have a superfetch feature like in vista which keeps ram full
Higher memory usage causes minimal/neglectable effect on power consumption, RAM is powered as a whole, fractional/partial modes (where only used memory cells are powered) are not available on modern RAM chips. The CPU or DMA controller may use more power swapping memory data in and out as memory usage grows, however the increase is nothing in comparison with what the LCD backlight or loudspeaker would use.
I don't know what memory allocation method is used in Windows CE/Mobile, but regardless, being unable to start a new application while there are no other applications running in the background means that physical memory is depleted and this is not normal. OS may use RAM for caching/buffering to optimize performance, however memory allocated for optimizations should probably be released when it's required for other purposes. If this is not happening, than either OS lost track of allocated/unallocated memory or memory allocation approach is very inefficient and causes high fragmentation.
Here's a list of tools (for WinCE) that may also work on WinMo and help curious xda-devs figure out what's eating their memory...
http://blogs.msdn.com/ce_base/archive/2006/01/11/511883.aspx
I have a i9505 and I updated to android 4.4 and I have an issue with high CPU usage, I may have had the issue on 4.2 too but I am not sure.
Occasionally I notice high CPU usage and my battery life is quickly starts falling. I see two android.process.acore using a lot of CPU and I cannot kill them. When I look at them they are both com.android.process.userdictionary and seem to refuse any attempt to end the process. The only apps I had used since booting the phone was whatsapp , gosms and email app (only to view and not reply to any emails)
I have not loaded any new applications and I cannot see what has called the userdictionary process and why it keeps coming up and using high CPU.
A reboot of the device solves the issue, but it will recur again at some point.
Help?
OK so this is getting worse now.I have had t reboot the device several times today to get rid of these acore issues.
pls can someone help?
brussel said:
I have a i9505 and I updated to android 4.4 and I have an issue with high CPU usage, I may have had the issue on 4.2 too but I am not sure.
Occasionally I notice high CPU usage and my battery life is quickly starts falling. I see two android.process.acore using a lot of CPU and I cannot kill them. When I look at them they are both com.android.process.userdictionary and seem to refuse any attempt to end the process. The only apps I had used since booting the phone was whatsapp , gosms and email app (only to view and not reply to any emails)
I have not loaded any new applications and I cannot see what has called the userdictionary process and why it keeps coming up and using high CPU.
A reboot of the device solves the issue, but it will recur again at some point.
Help?
Click to expand...
Click to collapse
I'm having this problem with my NoteII LTE (GT-N7105)
Trying to find a solution - but no luck thus far.
Did you solve the issue? krtccd is always on top with up to 40% CPU usage on my Samsung Galaxy S4
vak said:
Did you solve the issue? krtccd is always on top with up to 40% CPU usage on my Samsung Galaxy S4
Click to expand...
Click to collapse
I have the same problem and I don't know the exact reason why this happens, but it is due to a mess in the swap activity of the phone. If you have a rooted phone with a kernel that let you enable or disable zram (like googy max) so try to disable it.
I think that some memory leak or some app put the memory in a bad state screwing up the swap process.
The problem should be temporary stopped if, during the high cpu activity of the krtccd process, you make a "close all" from the multi tasking manager of your phone (accessible holding the home button).
I know it is a late reply, but this could be useful if someone search the forum for a solution.
mannybiker, many thanks for your reply!
mannybiker said:
I have the same problem and I don't know the exact reason why this happens, but it is due to a mess in the swap activity of the phone. If you have a rooted phone with a kernel that let you enable or disable zram (like googy max) so try to disable it.
I think that some memory leak or some app put the memory in a bad state screwing up the swap process.
The problem should be temporary stopped if, during the high cpu activity of the krtccd process, you make a "close all" from the multi tasking manager of your phone (accessible holding the home button).
I know it is a late reply, but this could be useful if someone search the forum for a solution.
Click to expand...
Click to collapse
could you recommend some app that detects processes with a high swapping activity?
vak said:
mannybiker, many thanks for your reply!
could you recommend some app that detects processes with a high swapping activity?
Click to expand...
Click to collapse
No vak, unfortunately I have not found any app that could show me the zram used per single processes. I kept the same rom with the same config for 9 months and never experienced any problem with krtccd, then suddenly it started to happen so I think this could be related to some update the phone has made to some of my apps. The only thing I could imagine to do is a debugging period making a titanium backup of all the apps, uninstall them all, verify that the problem is solved and start restoring them periodically one after the other seeing what happen, but for the moment I have just completely removed the zram from my kernel option. It is still a controversial feature that increase available memory but also cpu and then battery consumption.
I am not a Linux expert and I have not tested this on Android, but on Linux you can try to discover the swap usage per process with something like that:
Code:
for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less
So I managed to get my Nexus working by enabling only the little cores, however, I would like to try to get the big cores working.
Here's the console-ramoops I pulled from my device: https://pastebin.com/ddinyPzz
The first major error relating to the BIG cpu (that I noticed), was at lines 317 and 318 "_cpu_up: attempt to bring up CPU 4 failed"
However, the fatal error seems to occur at lines 439-451. Multiple errors about pll_clk_enable occur, here's some lines that I noticed.
Line 440: "variable_rate_pll_clk_enable: PLL a57_pll1 didn't lock after enabling for L value 0x50!"
And then at line 451: "Kernel panic - not syncing: failed to lock a57_pll1 PLL" From that point on, the kernel appears to go through the shutdown process.
For those who don't know, the cortex-a57 cores are the ones that make up the BIG cpu.
I tried to do some research on what PLL was (disclaimer, I am no expert whatsoever, so what I say may be wrong)
From what I could find, the PLL stands for phase-locked loop, and it's purpose is to control the frequencies of a CPU.
Intel has a post on possible causes for PLL losing lock: https://www.altera.com/support/support-resources/operation-and-testing/pll-and-clock-management/pll-loss-lock.html
I did some digging around in the kernel source code, and there are entries for "pll_clk_disable" in the PLL driver https://android.googlesource.com/kernel/msm/+/android-msm-angler-3.10-o-preview-3/drivers/clk/qcom/clock-pll.c
So maybe this means there's a way to somehow disable PLL?
So if any Devs, or anyone with experience on this, have an idea on how to possibly fix this, please give your thoughts. This problem is a relatively prominent one in this device, and it would be awesome if we could fix it.
Here's my questions to anyone who knows more about this,
Would it be possible to disable PLL?
Is PLL hardware based, or software?
And would it be possible to somehow build a kernel to fix this problem?
Caveat: I'm a mechanical, not electrical engineer. Take this with a huge grain of salt.
Phase locked loops can't be "disabled". They are a very important, low-level aspect of modern electronics. As you point out it is useful for signal synchronization such as a CPU bus. They also have many important electronic components, the failure of any single one will result a cascade of failures. So basically, I think your logs just further suggest it is a fundamental hardware issue.
As a theoretical example (this is completely made up by the way, my own hypothetical amateur understanding): let's say a solder pad is broken on the CPU or tin whiskers formed on one of the two signals for which the PLL comparator is operating. One signal will be a nice sine wave, the other will be random noise. The comparator output will be random noise. So in this case, the "PLL lock failure" will indicate a broken solder joint.
As another theoretical example (this is completely made up, etc.): let's say the Voltage Controlled Oscillator circuit develops a non-monotinic output, which is described in the video as sometimes occurring. (I'll just say "silicon wear".) This would result in system instability at certain frequencies. Ergo, another hardware problem. (In this case, maybe downclocking the CPU would be a test? Do the Big cores operate at different frequencies at boot?)
All in all I think it's great you got it this far, and is brilliant work. Way to go. I hope (*cough*) Google considers signing a "hotfix" firmware image that implements your workaround, so that people with locked/stock bootloaders may possibly have the opportunity to fix their phones. I'll pass this on to Techno Bill, our firmware volunteer guy. He's the one who successfully argued for publishing signed Full OTA "Rescue images" way back when. I'll ping whomever I can, and keep my fingers crossed.
Here's some helpful references:
https://www.electronics-notes.com/articles/radio/pll-phase-locked-loop/tutorial-primer-basics.php
https://www.youtube.com/watch?v=A9qt0JYdvFU
TL;DR: Likely still a hardware problem. I am out of the loop (pardon the pun) on this topic, and am only a volunteer so my views are my own, etc. However I suspect Google was being honest about it from the get go.
If you have a bootlooping phone, the official line from volunteers like me is to call in and ask about Warranty Service.
XCnathan32 said:
So I managed to get my Nexus working by enabling only the little cores, however, I would like to try to get the big cores working.
Here's the console-ramoops I pulled from my device: https://pastebin.com/ddinyPzz
The first major error relating to the BIG cpu (that I noticed), was at lines 317 and 318 "_cpu_up: attempt to bring up CPU 4 failed"
However, the fatal error seems to occur at lines 439-451. Multiple errors about pll_clk_enable occur, here's some lines that I noticed.
Line 440: "variable_rate_pll_clk_enable: PLL a57_pll1 didn't lock after enabling for L value 0x50!"
And then at line 451: "Kernel panic - not syncing: failed to lock a57_pll1 PLL" From that point on, the kernel appears to go through the shutdown process.
For those who don't know, the cortex-a57 cores are the ones that make up the BIG cpu.
I tried to do some research on what PLL was (disclaimer, I am no expert whatsoever, so what I say may be wrong)
From what I could find, the PLL stands for phase-locked loop, and it's purpose is to control the frequencies of a CPU.
Intel has a post on possible causes for PLL losing lock: https://www.altera.com/support/supp...g/pll-and-clock-management/pll-loss-lock.html
I did some digging around in the kernel source code, and there are entries for "pll_clk_disable" in the PLL driver https://android.googlesource.com/ke...3.10-o-preview-3/drivers/clk/qcom/clock-pll.c
So maybe this means there's a way to somehow disable PLL?
So if any Devs, or anyone with experience on this, have an idea on how to possibly fix this, please give your thoughts. This problem is a relatively prominent one in this device, and it would be awesome if we could fix it.
Here's my questions to anyone who knows more about this,
Would it be possible to disable PLL?
Is PLL hardware based, or software?
And would it be possible to somehow build a kernel to fix this problem?
Click to expand...
Click to collapse
Hey man, do you have your current kernel tree online? I a) don't own the device and b) am no expert. However, I am a very resourceful kernel hacker, and working around the impossible is my specialty. Just looking at the clk driver from the same source you shared, I can see some glaring issues in online cpu refcounting. Also the logs lean closer to device tree/platform data errors than anything else. Though the following init sequences should definitely be checking for the population instead of just progressing based on trust. I would be happy to submit some patches if you have a build up
Sent from my Note 3 using XDA Labs
robcore said:
Hey man, do you have your current kernel tree online? I a) don't own the device and b) am no expert. However, I am a very resourceful kernel hacker, and working around the impossible is my specialty. Just looking at the clk driver from the same source you shared, I can see some glaring issues in online cpu refcounting. Also the logs lean closer to device tree/platform data errors than anything else. Though the following init sequences should definitely be checking for the population instead of just progressing based on trust. I would be happy to submit some patches if you have a build up
Sent from my Note 3 using XDA Labs
Click to expand...
Click to collapse
The nougat kernel source for the 6P is here, not sure if that's the same thing as a kernel tree, correct me if i'm wrong. Thanks for working on this!
Nathan-K said:
Caveat: I'm a mechanical, not electrical engineer. Take this with a huge grain of salt.
Phase locked loops can't be "disabled". They are a very important, low-level aspect of modern electronics. As you point out it is useful for signal synchronization such as a CPU bus. They also have many important electronic components, the failure of any single one will result a cascade of failures. So basically, I think your logs just further suggest it is a fundamental hardware issue.
As a theoretical example (this is completely made up by the way, my own hypothetical amateur understanding): let's say a solder pad is broken on the CPU or tin whiskers formed on one of the two signals for which the PLL comparator is operating. One signal will be a nice sine wave, the other will be random noise. The comparator output will be random noise. So in this case, the "PLL lock failure" will indicate a broken solder joint.
As another theoretical example (this is completely made up, etc.): let's say the Voltage Controlled Oscillator circuit develops a non-monotinic output, which is described in the video as sometimes occurring. (I'll just say "silicon wear".) This would result in system instability at certain frequencies. Ergo, another hardware problem. (In this case, maybe downclocking the CPU would be a test? Do the Big cores operate at different frequencies at boot?)
All in all I think it's great you got it this far, and is brilliant work. Way to go. I hope (*cough*) Google considers signing a "hotfix" firmware image that implements your workaround, so that people with locked/stock bootloaders may possibly have the opportunity to fix their phones. I'll pass this on to Techno Bill, our firmware volunteer guy. He's the one who successfully argued for publishing signed Full OTA "Rescue images" way back when. I'll ping whomever I can, and keep my fingers crossed.
Here's some helpful references:
https://www.electronics-notes.com/articles/radio/pll-phase-locked-loop/tutorial-primer-basics.php
https://www.youtube.com/watch?v=A9qt0JYdvFU
TL;DR: Likely still a hardware problem. I am out of the loop (pardon the pun) on this topic, and am only a volunteer so my views are my own, etc. However I suspect Google was being honest about it from the get go.
If you have a bootlooping phone, the official line from volunteers like me is to call in and ask about Warranty Service.
Click to expand...
Click to collapse
Ok that makes more sense, thanks for clearing that up. I do know that some people have said simply underclocking their big cores have worked, personally it didn't work for me, but maybe I just need to clock it lower, I'm not sure. Regardless, it shocks me how blatantly erroneous the Nexus 5X/6P devices are, and somehow, Google/Huawei/Qualcomm/LG haven't done anything to address or fix the problem, other than Google and Huawei getting into a pissing contest over who's fault it is.
XCnathan32 said:
The nougat kernel source for the 6P is here, not sure if that's the same thing as a kernel tree, correct me if i'm wrong. Thanks for working on this!
Click to expand...
Click to collapse
For sure, I meant moreso if you were working on a kernel personally for it
Sent from my Note 3 using XDA Labs
robcore said:
For sure, I meant moreso if you were working on a kernel personally for it
Click to expand...
Click to collapse
I'm thinking of working on a kernel to optimize it for using only the little cores, for now though, I'm just trying to get this fix out to as many devices as I can. Apparently Qualcomm 808/810 SOCs have tons of problems.
XCnathan32 said:
I'm thinking of working on a kernel to optimize it for using only the little cores, for now though, I'm just trying to get this fix out to as many devices as I can. Apparently Qualcomm 808/810 SOCs have tons of problems.
Click to expand...
Click to collapse
If you do, please reach out to me. Judging from your logs, the big cores aren't being found during initialization, and the other errors (pll, clocks) are from assuming that the cores are already registered with the driver. Now, given that the big cores have been identified as the culprit for the loops, maybe we could work on a custom solution to delay their initialization to a later initialization stage.
While upstreaming a legacy device of mine, I had to rewrite the Qualcomm cpufreq driver in order to make it register with the cpufreq core, and it was a learning experience that would be a pity to keep to myself!
robcore said:
If you do, please reach out to me. Judging from your logs, the big cores aren't being found during initialization, and the other errors (pll, clocks) are from assuming that the cores are already registered with the driver. Now, given that the big cores have been identified as the culprit for the loops, maybe we could work on a custom solution to delay their initialization to a later initialization stage.
While upstreaming a legacy device of mine, I had to rewrite the Qualcomm cpufreq driver in order to make it register with the cpufreq core, and it was a learning experience that would be a pity to keep to myself!
Click to expand...
Click to collapse
This sounds promising, it's weird though how devices would randomly bootloop, not even right after an update.
My thought would be that, being that this is clearly a hardware issue, would there be a way to track it to a specific core? Then simply disable -that- core, rather than disabling all "big cores" as they're being referred to.
I have minimal experience related to this, but that's just what's on my mind at the moment.
kronflux said:
My thought would be that, being that this is clearly a hardware issue, would there be a way to track it to a specific core? Then simply disable -that- core, rather than disabling all "big cores" as they're being referred to.
I have minimal experience related to this, but that's just what's on my mind at the moment.
Click to expand...
Click to collapse
The issue is hardly any specific core but rather kernel/driver related to the whole BIG cluster as specified above. I think that if there were any real production defects they would have noticed them by now.
I have a Sony Z5C, which uses the same SoC and has a similar issue but is nowhere near as severe. Our hotplugging is inefficient and the CPU readings and IRQs were botched. Until recently the only viable/stable CPU governor was interactive (even on custom kernels)... Anything else gave erroneous data, locked frequencies, deteriorated performance and didn't survive a reboot (or 10 minutes of use) without defaulting back to interactive. We don't have reboots or lockups or anything but the issue's still quite similar once you think about it.
Is there anyway to enable one core in big cluster? If only part of the big cluster is bad, we can isolate it and use the other cores.
Booting with one core at a time we can test which one is the problem.
Maybe we could disable the core or set freq to 0? Or voltage to 0.
Sent from my Nexus 6P using XDA-Developers Legacy app
Pineapplelaw said:
Is there anyway to enable one core in big cluster? If only part of the big cluster is bad, we can isolate it and use the other cores.
Booting with one core at a time we can test which one is the problem.
Maybe we could disable the core or set freq to 0? Or voltage to 0.
Click to expand...
Click to collapse
Look at my last post.
XCnathan32 said:
This sounds promising, it's weird though how devices would randomly bootloop, not even right after an update.
Click to expand...
Click to collapse
Strange? Yes. Workable? Perhaps!
Something tells me the hmp scheduling has been a largely failed experiment as well. As well, the Google/oem sources are far from perfect, and every device needs its own specific workarounds for these types of issues.
robcore said:
Strange? Yes. Workable? Perhaps!
Something tells me the hmp scheduling has been a largely failed experiment as well. As well, the Google/oem sources are far from perfect, and every device needs its own specific workarounds for these types of issues.
Click to expand...
Click to collapse
I'm seeing this error "msm_thermal:Failed reading node=/soc/qcom,msm-thermal" and CPU-z doesn't report any temps for my device whatsoever, is this universal for 6p's? Or is it another problem with the SoC?
Edit: Also seeing this error? (not sure if it is an error) come up a lot "(name of module/driver)0 <--> 0 mV" Do you think it's possible that the BIG CPUs are somehow not getting power?
@XCnathan32 see . / drivers / clk / qcom / clock-cpu-8994.c
The pll lock bit is defined as BIT(31), which is the MSB of register pll->status_reg.
On the log you posted, pll->status_reg is 0xca000100 with MSB set, this suggests the pll has locked by the time that debug message has set.
Conclusion: the cpu is not giving the pll enough time to lock.
Suggested possible solution: change line 53 in clock-pll.c from #define ENABLE_WAIT_MAX_LOOPS 200 to #define ENABLE_WAIT_MAX_LOOPS 100000 to give the pll 100ms to attempt a lock.
programmargorp said:
@XCnathan32 see . / drivers / clk / qcom / clock-cpu-8994.c
The pll lock bit is defined as BIT(31), which is the MSB of register pll->status_reg.
On the log you posted, pll->status_reg is 0xca000100 with MSB set, this suggests the pll has locked by the time that debug message has set.
Conclusion: the cpu is not giving the pll enough time to lock.
Suggested possible solution: change line 53 in clock-pll.c from #define ENABLE_WAIT_MAX_LOOPS 200 to #define ENABLE_WAIT_MAX_LOOPS 100000 to give the pll 100ms to attempt a lock.
Click to expand...
Click to collapse
Will try it.
programmargorp said:
@XCnathan32 see . / drivers / clk / qcom / clock-cpu-8994.c
The pll lock bit is defined as BIT(31), which is the MSB of register pll->status_reg.
On the log you posted, pll->status_reg is 0xca000100 with MSB set, this suggests the pll has locked by the time that debug message has set.
Conclusion: the cpu is not giving the pll enough time to lock.
Suggested possible solution: change line 53 in clock-pll.c from #define ENABLE_WAIT_MAX_LOOPS 200 to #define ENABLE_WAIT_MAX_LOOPS 100000 to give the pll 100ms to attempt a lock.
Click to expand...
Click to collapse
Just realized this, would I need to uncomment "#define"? Because I would think that line would be ignored when commented.
XCnathan32 said:
Just realized this, would I need to uncomment "#define"? Because I would think that line would be ignored when commented.
Click to expand...
Click to collapse
No no this is the proper way to define things for the c preprocessor!
Damn, I hope I'm not offending anyone but, I feel very sad that I don't have a broken 5x/6p (and my nexus 5 does not want to die) to work on this fix.
Will follow this thread and help with whatever I can (which is limited to some C programming and a few linux kernel builds...).
Good luck and congrats for this progress.
Hey everyone, I just installed an android head unit in my car and i'm having an issue I can't seem to resolve. Its generic, so not sure of the brand, here are the specs.
✔LASTEST ANDROID 7.1 OS + POWERFUL HARDWARE: Build-in QUAD-CORE T3 K2001M(ARM COTEX-A7=high effect and low consumption version of ARM Cortex-A15, much better than COTEX-A9 ) 1.6 GHz CPU,1GB DDR3 RAM,16GB NAND Memory and Wifi,Bluetooth,GPS module
it says its 7.1, but my son said its actually 6.1 renamed as 7.1 as its still running marshmallow.
heres whats going on. any app that has sound, except the defult player, will autoclose when I leave the program. If i go to spotify, it will have the icon on the top, when i go back to my home screen, it will continue to play for 5-10 seconds, then go away and the music will stop. I'm completly new to android (switched from iphone and macbooks yesterday), and trying to get over this learning curve. any help would be appreciated!
It's probably the lack of RAM. You've only got 1 GB. The Android system uses a large portion and Google and its services (running in the background) also use a large amount. Then you've got Spotify running which is a huge memory consumer. The system just doesn't have enough to keep all programs fully running in the background. When an app is put on the foreground it has to reinitialize
This is common for 1 GB devices, be it tablet, phone or head unit. Over the years Google memory consumption has grown significantly. That is combination with Spotify is not ideal. If you can live without Google helping you, you could try stopping (freezing) most of its services. Also use a decent audio player like PowerAmp
This is definitely a RAM issue. As android runs out of RAM it will close off non essential apps running in the background.
thats what i was thinking, thanks for the help. How much ram is recomended for when I purchase my next one?
also, can more ram be added to these units? Also it won't let be disable apps, only force stop them.
dustrock said:
also, can more ram be added to these units? Also it won't let be disable apps, only force stop them.
Click to expand...
Click to collapse
Unfortunately, No. RAM is soldered directly on the motherboard.
How much RAM in a new unit then? Well, better to be save than sorry. Current mainstream head units, based on the PX5 (sold around $300), are equipped with 4 GB of internal RAM, which should be more than enough. Cheaper models have around 2GB, which should be good now but certainly is not future proof.
Depending on the Android version and/or firmware used can choose between 'Force stop' and 'Disable'. Disable prevents the app from being restarted at boot.
However, the system can prevent you to do this. If that's the case, you'll need to 'Root' (jailbreak in apple terms ) your device. Only then you'll have permission to disable a (system) app/services or delete it altogether.
thanks for the help! I just bought this unit to replace the broken factory stereo in my beater to see if I wanted to purchase one for some of my other cars. I guess I'll have to step up and get get one with some more ram.........and a damn volume knob. lol
I have a unit with 2 GB and I also have the same issue. In the past I had a head unit which also had 2GB of memory and did not face this issue. Is there any other solution for this?