Although I have no idea why don't you just use a linux-based live disk or virtual machine, the fact that you installed windows on an official mac hardware makes me assume that you would only use a windows-based solution for this task.
Although I don't use cygwin myself, the steps on the linked site seem to be fine.
Yep, with google migrating many apps to the play store (calendar, for example) we could just strip those out, and if one is using it, he can install it to /data from play. I am not sure if by removing these apks we can go below 160, with a 'core' gapps, but it's a first step to less whining.
Right now I'm not near a computer, but I would check recents commits to SystemUI & Settings ( dunno what's missing in your build, hadn't tried it ) with cd 'path-of-git-repo-for-<package>' && 'git log --oneline'.
Elnézést, kik "mondják"? Persze, a Google-alkalmazottaknak ez a dolguk. Time-memory tradeoff ismerôs fogalom?
Biztos optimalizálgattak itt-ott, de ezeknek a technológiáknak az egyidejû használata számításigényes:
Idôrôl idôre végig kell nézni a memórialapokat. Csak a CPU képes rá.
A tömörítést sem a GPU végzi, hacsak valahonnan nem kerítesz OpenCL-es drivereket adreno200-hoz, armv6-ra fordítva.
Az armv6 hivatalosan már egy ideje NEM kap támogatást a google részérôl, úgy kell visszahegeszteni a 4.X-es androidokra. Még ha kicsit csökken(het) is a memóriahasználat, az új JIT kódot armv7-re írták meg, nekünk marad a régi 2.3-ból átvett JIT kód foltozgatása.
Szép a reklám, csak nem a Bladenek szól. :(
Others: Sorry for not using english, I am too sleepy to translate that right now. Sum: see my previous post.
There's been a lot of changes under the hood. Even with the lower memory footprint, we have no idea about compatibility, storage requirements, etc. Also, it seems to make use of zram, ksm to achieve that ram usage, which - while really reduces memory footprint - increases CPU usage. While we truly have 512Mb ram, we also have a legacy armv6 processor, which google doesn't even supports, neither within android itself, nor within apps like google now.
PS: On the other hand, I recall KonstaT once said he likes a challenge, and he had already surprised us in the past. I wouldn't be surprised if he at least attempted a port, but don't keep your hopes too high - while 4.3 is a true miracle for our phones, every device has it's limits, and we have been on the borders for quite long now - KitKat may already be on the 'other side'.
These roms are made of the same base - but daemond's build is newer. It should have fewer bugs and more optimizations, and even more important: should have received more security updates both from him and the upstream cm repos.
Your issue sounds pretty much like a buggy application waking up the device, btw.
Have you tried to check for wakelocks first?
I *think* that although by adding an ld parameter I could get it working in case of the first object, the problem itself is very similar in case of notify.o
It fails because of that 'undefined reference' in the paste, but usbfs_mutex is declared in usb.h of the very same directory, and is included with
In case of msm72k_otg.o, the problem was the very same, as it got the same error with two methods declared in include/linux/usb.h, included with
Although I was able to continue compiling by adding notify.o as an input parameter of ld.
But in case of notify.o, I have no idea what could I do to fix it (apart from the ugly copying of the contents of usb.h instead of including it, which in theory does the same). The preprocessor doesn't give a warning, it only fails at linking.
Okay, it seems like the current kernel sources fail to compile with OTG enabled, but it seems to be just a few missing prototypes until now, so nothing too hard. I guess it's a remaining piece of mess from the original zte code release, layed hidden in unused ifdefs.
P.S: I have been too optimistic. The first error was indeed a missing a prototype, but now I just can't sort out that 'undefined reference' in a way that doesn't involve ugly things like copy from header and paste into c file. I will try collect some outputs and post it there, because I'm no C jedi, and I ran out of ideas after spending hours googling the issue. I am however, now more interested in it than ever, so I guess I won't be sleeping well unless I sort it out. :(