Related
This thread is now obsolete.
Kernel sources for build 5.26.0 have been released:
https://opensource.motorola.com/sf/go/projects.milestone/frs.milestone_source_froyo
I've pushed some new pre-compiled modules to github, though beware, I haven't had time to test all of them on device yet:
https://github.com/nadlabak/android...mmit/b300803348705d3fc5ce76d8c88d57186748a370
As the kernel sources are not yet available from the Motorola's open source project, here is an outline how I compiled the overclock and cpufreq governor modules. (Btw., the overclock module needed a substantial adaptation, see the source here: http://android.doshaska.net/2.6.32oc )
I'm using the sources from this AOSP repo:
Code:
git clone git://android.git.kernel.org/kernel/omap.git
git checkout --track -b android-omap-2.6.32 origin/android-omap-2.6.32
Use the sholes config:
Code:
make sholes_defconfig
flags that need to be disabled:
CONFIG_LOCALVERSION_AUTO
CONFIG_MODVERSIONS
CONFIG_DEBUG_MUTEXES
CONFIG_SCHEDSTATS
CONFIG_SCHED_DEBUG
[updated on 17.01.2011, thanks go to Skrilax_CZ]
At least the ext2 will work without panics when compiled using this config.
For tun, cifs and nfs there is still some additional config mismatch that prevents the modules to work without null pointer dereference oops.
Also, even when no custom kernel module is used, you can get the kernel panic very easily, try to enable wifi and do:
Code:
cat /proc/kallsyms
If you're interested in a more detailed android kernel compilation guide, you can e.g. roughly follow this Droid kernel guide: http://www.droidforums.net/forum/rescue-squad-guides/31452-how-compile-your-own-kernel.html
Thanks for starting this thread kabaldan! It is a great starting point in tackling the issue of adding tun support to the new kernel (tun.ko module). I am not as good as many others in this, but trying won't hurt. Meanwhile if someone else is working on tun support - share experience here!
If kernel seems to be ok, sometimes mounting with new version of busybox won't work.
I used to get kernel panic when use newer version of busybox (not Android kernel but my own embedded linux)
Hey Nadlabak can you add DLNA function of CM6?
same problem using droidx kernel sources. insmod ok, mount reboots the phone
yantz
I tried droid2 kernel module - doesn't work either
I noticed OpenVPN included in CM6 also relies on this kernel module. Hence doesn't work. I guess we won't (ever) see kernel sources for that leaked kernel we are now using. I assume Motorola will release the sources sooner or later, but not before official Froyo layout. The waiting is killing me! kabaldan, can't you try to do some magic as you did with the overclock module? The beer is from me!!!
Can you test this attached tun.ko?
Insmod is OK, but I currently don't have time for any further tests...
EDIT: don't bother, kernel panic as usual
Module loads fine, but when attempt to use it, phone reboots, just like with the module compiled from DroidX sources..
leobg said:
Module loads fine, but when attempt to use it, phone reboots, just like with the module compiled from DroidX sources..
Click to expand...
Click to collapse
So, I got it loaded - insmod works just great, just like it did on the 2.1 kernel.
I'm trying to use the CM6 built-in OVPN settings, but I can't find any documentation on the setup. How did you get it set up?
I have
/sdcard/openvpn/
cert.crt
ca.crt
config.conf
config.ovpn
pem.key
I realize that config.conf and config.ovpn are the same file- but I use this VPN on windows and on Mac, and I wasn't sure the requirements on Linux.
If I can't find some documentation I'll try downloading the OpenVPN settings app from the market and playing with that.
Also, I don't know if it's true or not, but I heard the Milestone2 source compiled driver could work.
Are you trying the module kabaldan provided? It doesn't seem to work, at least for me. Loads fine, but phone crashes when setting up tun interface. I couldn't get OpenVPN in CM6 0.3 to work so far. I am testing the tun.ko with the cisco vpn package (which worked great on the old kernel with CM6 0.2) vpnc. When I initiate the connection, phone reboots if the attached here tun.ko is used. I also tried with tun.ko compiled from DroidX sources - same thing - phone reboots. I am not sure where did kabaldan take/compile this module from.
Sent from my Milestone using Tapatalk
I was using the same one, I was thinking maybe he could use the info from more than one phone. I'll try get-a-robot or OpenVPN Installer, but I won't hold my breathe. I was just hoping to use the built-in functionality of the ROM.
*edit* Just saw he removed it because it doesn't work yet, oh well.
the kernel doesnt seem to like any other fs not built into it. i've tried several, ext2, ext3, ext4, cifs, jffs, reiserfs etc. all modules would load without a problem but system will reboot during mount. heck i even tried creating logical volume on the partition. volume created fine, but when time to mount, it reboot
i ended up using a 2nd vfat partition for apps2vfat, on top of native froyo move to sd. moved my debian arm there and manually, yes manually, replace many symlinks in libs to copied files
hopefully next froyo release for other regions would provide a different kernel
yantz
hey kabaldan wondering if you've had another chance to look at an updated tun.ko
Finally some breakthrough. The great Skrilax_CZ has made some hard debugging and one very good guess:
CONFIG_DEBUG_MUTEXES must be disabled in the kernel config.
At least the ext2 module compiled this way is working without panics now.
Congrats to Skrilax!
EDIT: Tun nor nfs not tested yet..., cifs unfortunately still not working.
kabaldan said:
Finally some breakthrough. The great Skrilax_CZ has made some hard debugging and one very good guess:
CONFIG_DEBUG_MUTEXES must be disabled in the kernel config.
At least the ext2 module compiled this way is working without panics now.
Congrats to Skrilax!
EDIT: Tun nor nfs not tested yet..., cifs unfortunately still not working.
Click to expand...
Click to collapse
This means that now the app2ext work?
Where are the modules for we test?!
Thanks for the news!
Modules for testing:
ext2 - http://code.google.com/p/cyanogenmod4milestone/issues/detail?id=197#c19
tun - http://code.google.com/p/cyanogenmod4milestone/issues/detail?id=222#c4
Hi sort of a newbie here... So does this mean that data2ext will work?
Sent from my Milestone using XDA App
Hi Nadlabak...maybe you already know.
For the cifs module, how about slow-work is made available as a module.
as is done at this link
http://forum.xda-developers.com/showpost.php?p=9271775&postcount=4
after further testing:
ext2 mounting now works, reading from ext2 partition too, but writing still causes panic
tun causes panic too
Let's hope for a soon kernel source release, as it looks like we won't get much further without it.
edowar: thanks for the link
@kabaldan
Could it be possible to create a swap module for milestone ?
It seems that running kernels does not have this feature yet and i'm not sure motorola to implement it for next 2.2 release so .... well just wondering !
Hi all
Introduction
I cannot call myself a developer or a kernel master at all. I'm just good at discovering and learning new things and in fact that's the way my journey with kernels started. At this point I want to start a new thread for something different from my earlier work, porting Boeffla kernel.
Features included:
Compiled with 4.9 Linaro toolchain
CPU OC up to 1600Mhz
ZZmoove as default governor (with moderate profile) - best for smoothness/battery life
Zen and Row I/O schedulers
Undervolting interface introduced
Configurable Touchboost
Configurable Touchwake
Charging interface
Boeffla Sound 1.6.6
Dynamic Fsync
Switchable Sharpness Tweak
Led configurable (fading, strength)
Configurable Android logger
Configurable printk logging
Readable: asv level, CPU temperature
Disabled some debug
Few minor tweaks (check github if interested)
If I forgot something - Github is up !
What kernel features may we expect?
F2FS support
Dualbooting support (if I can handle it properly)
What you say?
Compatibility
Flash only on proper roms!
As for now we have only Lollipop version, compatible with NamelessRom (you may try with others LP).
Download
You can download the most recent kernel here -> Click
Source
Github link - Click
Credits
These men never refused to give me a helping hand, advised me what to do and, more important, without their work this kernel wouldn't even exist (opensource doesn't mean no respect!).
@JustArchi
@Lord Boeffla
@Yank555
@ZaneZam
@arter97
Samsung :good:
Disclaimer
*** As always - Flash on our own risk! ***
Make sure you flash the correct version depending on your firmware version!
I can't and will not take any responsibility for bricked phones or lost data.
It is generally recommended to run a complete Nandroid backup in CWM recovery and safely store your personal data before you flash anything.
Camera bug info: (hidden, only applies to Samsung ROMs)
It appears that some people (like me) have problem with camera. In exactly THIS situation: do full wipe, flash sammy rom+boeffla kernel, reboot and launch camera. Effect? Camera closes with "camera failed" popup.
Possible solutions:
Option 1 is good for people that rarely change their ROMs (and it fixes EVERYTHING), whether option 2 is better for people changing their ROMs more frequently (however, it's always good to have backup of your SlimISP on sdcard).
Option 1. Flash Sammy Rom with stock Sammy kernel, run the camera, take a photo, then reboot to recovery and flash my HboKernel
Option 2. Flash Sammy Rom with stock Sammy kernel, run the camera, take a photo, grab file (SlimISP_XX.bin, where XX differs between phones) from /data/cfw/ and backup it where you want. Then if you can always copy it to /data/cfw if your camera doesn't work with my ported kernel. (ATTENTION: Unfortunately this file does not always appear - still don't know why )
Option 3. Read this thread and follow steps --> click
Possible explanation, my own research:
I found out that people with ZD and GD will have camera working always. Why? Because these (SlimISP_XX.bin, where XX differs between phones) files are packed within kernel (zImage exactly) and ONLY THESE two are provided by Samsung in their opensource release... Interesting, isn't it? For example, I have GH version, which I may add to zImage manually, however adding more of them breaks the size limit for boot partition, so it's impossible to have all these versions together. However, stock kernel somehow has them, don't know how because zImages aren't extractable.
And just to confirm my theory, I've compiled a kernel with mine version of camera firmware, made full wipe, installed sammy rom+my kernel, rebooted, launched camera and voila - it worked
Thus, we has to live with this bug unless Samsung do something about it or someone else proves me that I'm wrong
I say, may good luck be with you accomplishing these features in the kernel :good:
Best of luck with this project Hbohd
Thanks to you, there is some life potential remaining for i9305!
Long life to i9305 and may the (dev) force be with you HboHd!
Thanks for your work!
+1 Nice one.
Hbohd said:
What you say?
Click to expand...
Click to collapse
I say: it's freaking interesting!!!!
Just a supposition , for the future , the MDNIe hijack for more natural colors would be great , i'm waiting the F2FS version to switch to NI3
aaz03 said:
Just a supposition , for the future , the MDNIe hijack for more natural colors would be great , i'm waiting the F2FS version to switch to NI3
Click to expand...
Click to collapse
Hmm.. Isn't 'Screen mode' under Display settings enough? It gives a little bit of difference without need of additional kernel's code modification.
New alpha 0.1
Okay, to keep this project alive, to show off some progress step by step and to satisfy flashoholics - I've decided to release my small achievements in form of alpha kernels
Firstly, let's restart naming convention of the kernel. It will be simple x.x now, starting from available below 0.1 version :cyclops:
Small changelog:
removed debugging in many places
compiled with linaro 4.9
few tweaking commits
Let's say that due to my 'stupidity' or magic ability to forget something, I've spent on it many hours today :silly:
Is Insecure ADB fixed?
Just gave the new version a flash, insecure adb wasn't set. I've fixed it up and attached it.
@Hbohd if you want to patch this in later veresions, make these changes to the /ramdisk/default.prop
- change ro.adb.secure=1 to 0
- change persist.sys.usb.config=mtp to mtp,adb
then just copy the adbd file from my /sbin
This is for old bootloader only?
SE disabled on 0.1?
it says nothing in system anymore below build
you should maybe consider a txt file in the zip and jot into it every time you change something before you forget
v0.2
tweaked this
added that
etc..
@Hbohd tks for your excelent work!!!, one notice, the I9305 didnt charge the battery when is off. Only, starts and boots normally, and there starts charge. Its only a detail, but in my case Important. Tks again for your work!!!!
ShonkUK said:
SE disabled on 0.1?
it says nothing in system anymore below build
you should maybe consider a txt file in the zip and jot into it every time you change something before you forget
v0.2
tweaked this
added that
etc..
Click to expand...
Click to collapse
sham79 said:
This is for old bootloader only?
Click to expand...
Click to collapse
I haven't stated anything different from what is true I mean, if I write that you can you use it with new bootloader or SE is disabled - then it would be true
I think that in next release I will disable it (simply forgotten due to my compiling problems mentioned earlier).
Oh, and I don't need another changelog when everything is written in the git I haven't just suceeded in uploading it to the github yet :/
machotecba said:
@Hbohd tks for your excelent work!!!, one notice, the I9305 didnt charge the battery when is off. Only, starts and boots normally, and there starts charge. Its only a detail, but in my case Important. Tks again for your work!!!!
Click to expand...
Click to collapse
Yeah, someone mentioned it already. I will try to fix it for next version, thanks!
djb77 said:
Just gave the new version a flash, insecure adb wasn't set. I've fixed it up and attached it.
@Hbohd if you want to patch this in later veresions, make these changes to the /ramdisk/default.prop
- change ro.adb.secure=1 to 0
- change persist.sys.usb.config=mtp to mtp,adb
then just copy the adbd file from my /sbin
Click to expand...
Click to collapse
Will be in for the next so-called 'alpha'
Just to be sure, Is "HboKernel alpha v0.1" an update of previous "HboKernel v2" of boeffla thread ? Same source + small changelog you @Hbohd mentionned in post #10 ?
fpriot said:
Just to be sure, Is "HboKernel alpha v0.1" an update of previous "HboKernel v2" of boeffla thread ? Same source + small changelog you @Hbohd mentionned in post #10 ?
Click to expand...
Click to collapse
Yep, you are right
If I may suggest @Hbohd... Could you please start with the power features implementation? Charging rates, ignore unstable power and margin...
Because these are the ones I really miss... My chargers and/or cables are not good and I need these mods to charge properly...
Thanks!
Firsty thanks for all your hard work.
The phone no longer charges from the car dock. This was the same for the stock kernels in 4.1.2 & 4.3 - still withold bootloader. 4.1.2's was fixed with Pegasus kernel and 4.3 was fixed by your Beoffia 5 kernel.
Hello, i bring to you the QuickRemote app for your AOSP Marshmallow rom, CM13 or any rom based on CM13 (Resurrection Remix, Bliss, AICP), you may ask, "Why would i want QuickRemote on my AOSP rom if MM has native IR support and Peel or Anymote works without all this mambo jambo?
Well, even though what i just said is true, no remote controller app has the learning method enabled, even on a stock rom, only QuickRemote can enable the IR receiver to learn a controller that does not appear on the device/manufacturers list.
So, that's the reason we want QuickRemote to work on our AOSP rom.
So, before anything, i would like to thank @hikarisei23 because in a comment of his post HERE i found the files for QuickRemote to work on MM wich leads to the second person i want to thank wich is @syndre who on said comment, posted the files that worked on MM, also @KronicSkillz who helped a lot to troubleshoot and also confirmed that the method i'm posting here works.
Well, this is it, after personally testing with: Resurrection Remix, AICP and Bliss, all of them MM amd CM13 based, all of them with the stock kernel and Lambda Kernel i'm confident enough to post it here, days of testing and troubleshooting and 3 different roms later.
So first, the mandatory disclaimer, im not responsible for any problem that may result from using my method and the files i'm providing you, either with your phone or your self-esteem, it's your responsibility to read, re-read and only do what you are comfortable with.
What you will need:
1. - The phone, this only has been tested with Lg G2 and Lg G3, this may or may not work on another LG phone with IR, you can try, but at your own risk.
2. - The Rom, this only have been tested with AOSP roms either CM13 or CM13 based roms, again, you can try in another rom but at your own risk.
3. - Obviously a Custom Recovery (twrp, cwm, philz)
4. - The three zips im leaving at the end of the post, QRemote_AOSP_MM.zip Fix_Part1.zip and Fix_Part2.zip.
5. - Maybe necessary or not, depending on your rom, Universal init.d from Playstore HERE and Selinux Mode Changer from HERE.
6. - Root Access.
Ok, once you checked and have everything needed, we have to make a little prep on your Rom before starting to flash the zips.
Rom Preparation 100% Needed
You need to set Selinux to permissive, here is where you may or may not need Selinux Mode Changer, First go into "About Device" on your phone settings and in the bottom you will find an indicator for Selinux state, if its "Permissive" you are good to go, some Roms and Kernels have this set to Permissive by default, if it's Enforcing, search in your Rom or Kernel settings, some of them have an option to set it to Permissive, if your rom does not have any option to change it, you will need Selinux Mode Changer, you install it and set Selinux to permissive, after reboot you can check in About Device again to see if it succeded, if it does not work, try again and check the original post, most of the answers are there, i cant give support for this app, also, this app needs root rights, and preferably two reboots after setting Selinux to Permissive.
Next you need to have init.d support, again, some roms have it, but at least for the test that me and the other users did, even though you are pretty sure init.d is enabled it's better to just install Universal init.d from the Play Store and enable init.d manually after doing so, reboot the system at least two times and grant Root access.
Installation!
Now we are ready to start flashing, reboot into recovery and RECOMMENDED, do a Nandroid Backup just in case, but at the moment no boot loops or any other problems had raised from flashing this, but again, just in case. After that, flash the first file: QRemote_AOSP_MM.zip, reboot your system and let it settle for a bit, 1 minute at least.
Now is the part where almost everyone has problems, you have to check in your Sdcard root for a log file named Qremote.log, if the file is there, it means init.d is enabled and in the file it will say if Selinux is Ok, if you don't have the file, check back the first two prep steps and try again.
Now if everything is going ok, is time for the second file, Fix_Part1.zip, reboot and let the system settle again, you may have some force close errors from QuickRemote or QuicksetSDK, its ok, you can try and check if QuickRemote is working, in allmost every case it will not work just yet, but you may have some luck.
Now, is the time to flash the third file, Fix_Part2.zip, again, reboot and let the system settle, now, you should have a working QuickRemote app on you AOSP MM Rom.
This are the steps, if you need more information about what all of this is doing and why you need Selinux and init.d, also why you need to flash 3 files, you can read the troubleshooting section where i explain what i understand about it.
TROUBLESHOOTING
Well, if you are here, it means that this didn't work as planned, so lets make this like a FAQ so you just search your problem and get the answer for it.
P.- I can't see QuickRemote on my app drawer. A: be sure that QuickRemote.apk is not showing as "com.lge...." and has the default green Android icon on your app drawer, sometimes and for reasons unknown to me, this happens for the first day or so, it will automatically change to QuickRemote and it will have the correct icon at least 5 hours after you installed it, it can take more time. A2: Maybe the flashing proccess was not successful, re-flash the file, it will automatically delete previously flashed files and install a new copy of them.
P. - I get force close messages for QuickRemote or QuicksetSDK after completing the proccess. A: try to run QuickRemote after the system settled, most of the times is 1 minute, in some roms and for reasons unknown to me, this messages will appear at boot but after the system settled, you will be able to run QuickRemote without any problem.
P. - QuickRemote opens up but no manufacturers are showing and it also gets really slow. A: this problem shows when either QuicksetSDK is not correctly installed or Selinux is not set to permissive, the solution for the first problem is in my 2 part fix, the version of Selinux included in the first zip, works great with MM but for some reason it will not work out of the box, i dont know if it's missing some files but it may or may not even show under system apps list on your settings menu, what my 2 part fix does is that, deletes the version of QuicksetSDK that the first flash installs and installs a temporary copy of QuicksetSDK wich i believe, writes information needed for QuicksetSDK to work properly, but this newer temporary QuicksetSDK apk, will allmost never work on MM, you can try but allmost every time it will not work, it will constantly force close, so the second fix zip, will delete this temporary QuicksetSDK and the folder it creates in your Sdcard root and install the previous version of QuicksetSDK again, and now, if everything went well, it will work as it's supposed to, i really dont know why exactly, but it works.
A2: the first thing you will notice when you switch to MM is that allmost every app will ask for permission to your Sdcard or camera or microphone wich in LP was not doing, since 4.3 Google is taking extra steps to ensure that you and your information are better protected one of this steps is Selinux (Security Enhanced Linux) wich, for putting it in simple terms, is like a sandbox for your system, only some trust-signed apps can get out of that sandbox and copy files etc... Into your system, those not-so privileged apps cant output anything outside the sanbox and thats why you need to disable or "set to permissive" Selinux, so QuicksetSDK can make the changes necessary for QuickRemote to do its work, it's true that now your system is in a degree "more vulnerable" but if you are a user of this forum, the odds to install something that will damage your system or jeopardize your information are minimal, you need to be really silly to fall for those "your system has problems" or "your battery is gonna explode if you don't install this app" ads that appear on your phone on the daily basis, so, dont worry, but at the same time, just be carefull and have some common sense, if there is a way for this to work with Selinux set to Enforcing, i will update it in the same second.
P. - QuickRemote force closes whenever i try to open it. A: this is caused by either a bad zip flash, or problems with Selinux or init.d, follow the previous answer and the first installation steps again.
P. - I can see QuickRemote and QuicksetSDK on my apps list, no force closes but still no manufacturers. A: Be sure init.d is enabled, i had problems with Roms that had "native init.d support" and emulated init.d will not work, the only way i got no problems with this was with Universal init.d, install that even though you are "pretty sure" your rom supports init.d, the 10QuickRemote.sh script on your init.d tries to get your country to see if you will use the app in, either Korean or any other supported language, it will also give some permissions to a file and it will check if Selinux is Permissive and finally, it will log this to a file called Qremote.log on the root of your Sd, if you have problems and you cant see the file, the problem is 99% most of the time, init.d.
P.- I don't want to flash three files, isn't there a simpler way? A: Unfortunately no, at this moment and after A LOT of testing etc... This is the only effective way i found.
P. - I'm afraid to set Selinux to permissive and leave the door open for all kind of bad ju ju and stuff to invade my sacred Android system, what can i do? A: Skip this hole thing, at the moment, the only way to make this work on AOSP MM is by doing the previous, just be careful, get some common sense and everything will be just fine.
Well, thats all i can think of right now, if you have suggestions, problems or a better way to make this work, please tell me in the comments or PM me, i'm glad to help as far as i can, i hope this helps, i leave you with the needed files and proof that it works.
QRemote_AOSP_MM.zip - MEGA - DRIVE
Great job
Works great on Ressurection Remix 5.6.2. Well done.
Only issues I have are the force close when trying to edit the remote name, and icon and name of the app not showing correctly (which can be fixed with any custon launcher).
Petrit Ziu said:
Works great on Ressurection Remix 5.6.2. Well done.
Only issues I have are the force close when trying to edit the remote name, and icon and name of the app not showing correctly (which can be fixed with any custon launcher).
Click to expand...
Click to collapse
I have not seen those force closes, i have to check, and as i said, the icon and name will eventually get right, for me was 5 hours, but it can be a hole day, and all by itself will set the icon and name correctly, if you have more problems, send me a logcat for this app, maybe we can find why it force closes
Logcat
Logcat
Added to index
[INDEX][LG G2] ROMs, Kernels, Guides and more
@Petrit Ziu after seeing the logcat i think the problem is StrictMode Policy, wich is a policy in android to keep unintentional writes to the system away from the main thread, so the animations, ui etc... Can keep a steady flow and your system runs smooth, because this app was never intended for AOSP and the app comes from Lollipop, i think that the right signatures are missing and Android sees the action of changing the name to a controller "invalid" so it closes the QuickRemote App, lets wait for newer versions of QuickRemote after Lg releases MM to more IR enabled devices to see what app works best, this is the best we can do with the resources we have
@Art Vanderlay Thanks
@Jc_master I think it's already perfect, just pointed an issue i found, but it's totally not a problem for me. Thanks
Sent from my LG-VS980 using XDA Free mobile app
@Petrit Ziu thanks, and dont worry, i'm no developer but i'm learning so much from this, it's good for me to see this problems and know why they happen, it's good to have feedback and even better this errors, if you didn't tell me, i would not know, my system does the same and i had no idea, i will update the post with this information
not work for me
I flashed it a lot of time and patched it and it will be not even work for me :/
I always get FC
D802 CM13 Nightlies
Potter92 said:
I flashed it a lot of time and patched it and it will be not even work for me :/
I always get FC
D802 CM13 Nightlies
Click to expand...
Click to collapse
Well, the only thing i can reccomend is that you use the latest TWRP for your device, you have to follow the steps exactly as i explained and use exactly the apps and files i explain, if that does not work i can just reccomend using another rom, Resurrection Remix for example, your logcat seems to show a problem with the apk itself, you cam try and decompress the files and manually copy and assign permissions to the files but i can't show you how, i lack time to do it
Works great, thank you!
Only issue I've had is the app crashes every time I try to rename a remote.
It works on the D801 (T-Mobile) Bliss rom 6.0.1
just confirming it.
Although I do get some force quit when editing the remotes name etc...
LG D802 CM13 nightlies - works!
Jc_master said:
@Petrit Ziu after seeing the logcat i think the problem is StrictMode Policy, wich is a policy in android to keep unintentional writes to the system away from the main thread, so the animations, ui etc... Can keep a steady flow and your system runs smooth, because this app was never intended for AOSP and the app comes from Lollipop, i think that the right signatures are missing and Android sees the action of changing the name to a controller "invalid" so it closes the QuickRemote App, lets wait for newer versions of QuickRemote after Lg releases MM to more IR enabled devices to see what app works best, this is the best we can do with the resources we have
Click to expand...
Click to collapse
Is there a fix?
MM is out for G3
Thanks
U can change name using SQLite Editor like this:
https://play.google.com/store/apps/details?id=dk.andsen.asqlitemanager
Database: /data/data/com.lge.qremote/databases/qremotesettings.db
Table: tblDevices
Petrit Ziu said:
Works great on Ressurection Remix 5.6.2. Well done.
Only issues I have are the force close when trying to edit the remote name, and icon and name of the app not showing correctly (which can be fixed with any custon launcher).
Click to expand...
Click to collapse
I can confirm this force close on rename issue as well
Eselter said:
U can change name using SQLite Editor like this:
https://play.google.com/store/apps/details?id=dk.andsen.asqlitemanager
Database: /data/data/com.lge.qremote/databases/qremotesettings.db
Table: tblDevices
Click to expand...
Click to collapse
That did it! Not necessarily a solution to the problem but a sufficient workaround for now
On CM13 working great but on exodus I can't manage it to work.
Any one have try it on exodus rom?
Eselter said:
On CM13 working great but on exodus I can't manage it to work.
Any one have try it on exodus rom?
Click to expand...
Click to collapse
Same here. Works on every rom I've tried but exodus. Something funky is happening with the quickset SDK as its present in priv-app or app (forget which one) but doesn't show up in installed apps. I have selinux set to permissive and init.d enabled.
Hello, how to uninstall this qremote? Because I have tried peel smart remote, and it's works great. And the remote (peel) so detail from LG qremote.
Quick Camera Fix #1
Installation:
1. Download CM13 based ROM made by transi1
2. Open and replace files from temp_camera_fix_from_BEANSTALK_6.20.zip to the ROM of your choice respectively (flashing doesn't work)
3. Flash ROM, GApps etc.
4. After installation of ROM, install Open Camera or other 3rd party camera app
DOWNLOAD #1
temp_camera_fix_from_BEANSTALK_6.20.zip
Description:
This is basically a 3.0.72+ kernel from BeanStalk 6.20
IT WAS TESTED ON: RR 5.7.3, Bliss ROM
USING TWRP 3.0.2-1 WITHOUT TEMP_TOUCH_FIX
DOWNLOAD #2
temp_camera_fix_from_RR_5.6.5.zip
Description:
This is basically a 3.0.72+ kernel from RR 5.6.5
DOWNLOAD #3
temp_camera_fix_from_AICP_11.0.zip
Description:
This is basically a 3.0.72+ kernel from AICP 11.0
Want to support development? You can consider donating, my email is [email protected]. I spent countless of hours with this
NOTE: Fix from BeanStalk 6.20 is updated (deep sleep issue fixed).
-------------------------------------------------------------------------------------------------------------------------------------------------
Quick Camera Fix #2
FLASHABLE ZIP
-------------------------------------------------------------------------------------------------------------------------------------------------
NOUGAT EMOJI FLASHABLE ZIP
-------------------------------------------------------------------------------------------------------------------------------------------------
OMNISWITCH FLASHABLE ZIP
-------------------------------------------------------------------------------------------------------------------------------------------------
THREAD CLOSED
Interesting workaround. If it works, it's even more evident that we're dealing with the 3.0.101+ kernel. I'm still planning on going through with that kernel backtracking to see which version or commit started this mess, and once I find it, report it so we can hopefully work through this. IIRC, those files were compiled against the 3.0.72+ kernel, so they might be a little old. Can someone try out the patch and see how it affects stability?
monster1612 said:
Interesting workaround. If it works, it's even more evident that we're dealing with the 3.0.101+ kernel. I'm still planning on going through with that kernel backtracking to see which version or commit started this mess, and once I find it, report it so we can hopefully work through this. IIRC, those files were compiled against the 3.0.72+ kernel, so they might be a little old. Can someone try out the patch and see how it affects stability?
Click to expand...
Click to collapse
2016/02/20 is the date of creation of last AICP. So, we need to find commits since that date and before.
alexander_32 said:
2016/02/20 is the date of creation of last AICP. So, we need to find commits since that date and before.
Click to expand...
Click to collapse
I already forked the repos prior to the post-3.0.72+ commits. I'll link in the manifest file I created if you're interested in building against them.
monster1612 said:
I already forked the repos prior to the post-3.0.72+ commits. I'll link in the manifest file I created if you're interested in building against them.
Click to expand...
Click to collapse
Yes, bring it, please.
alexander_32 said:
Yes, bring it, please.
Click to expand...
Click to collapse
Here's the manifest file for building against those repos. I'm going to backtrack through the commits by forking the original repos at different points in time. Obviously, the old repos I forked before the 3.0.101+ commits are going to stay as they are for the time being until the issue is pinpointed and fixed once and for all. After that, I plan on deleting the manifest file and repos. Make sure that you run repo sync --force-sync on your build tree after replacing the manifest file and make clean to revert the kernel, or you'll still have remnants of 3.0.101+ lurking in the builds.
monster1612 said:
Here's the manifest file for building against those repos. I'm going to backtrack through the commits by forking the original repos at different points in time. Obviously, the old repos I forked before the 3.0.101+ commits are going to stay as they are for the time being until the issue is pinpointed and fixed once and for all. After that, I plan on deleting the manifest file and repos. Make sure that you run repo sync --force-sync on your build tree after replacing the manifest file and make clean to revert the kernel, or you'll still have remnants of 3.0.101+ lurking in the builds.
Click to expand...
Click to collapse
Thanks.
Like I said to @alexander_32, I tried reverting the u-boot.bin commits that Transi made a couple months back for the aicp build. It booted, ran really slow, and OpenCamera still saw the camera module as being in use. Using the current boot binary things run nice and fast again. The build I ran off last night testing a couple more things also did not have any effect on camera...
electrikjesus said:
Like I said to @alexander_32, I tried reverting the u-boot.bin commits that Transi made a couple months back for the aicp build. It booted, ran really slow, and OpenCamera still saw the camera module as being in use. Using the current boot binary things run nice and fast again. The build I ran off last night testing a couple more things also did not have any effect on camera...
Click to expand...
Click to collapse
Probably it something else. Did you check my method by the way?
electrikjesus said:
Like I said to @alexander_32, I tried reverting the u-boot.bin commits that Transi made a couple months back for the aicp build. It booted, ran really slow, and OpenCamera still saw the camera module as being in use. Using the current boot binary things run nice and fast again. The build I ran off last night testing a couple more things also did not have any effect on camera...
Click to expand...
Click to collapse
What'd you happen to test with last night's build? Also, was it my u-boot commit that caused the problems or before that?
monster1612 said:
What'd you happen to test with last night's build? Also, was it my u-boot commit that caused the problems or before that?
Click to expand...
Click to collapse
I tested a couple of camera specific build tags in bowser common and tate. They didn't work. When I get a chance later on, I plan on diving into it again.
@alexander_32: Not sure why, but I can't boot using this with the rom you posted here. It stays on the boot logo indefinitely. After a clean install and making sure it boots fine once, I'm manually flashing the boot.img in the zip and copying the contents of the modules dir while fixing permissions afterwards. Is that all there is to it or am I missing something?
r3t3ch said:
@alexander_32: Not sure why, but I can't boot using this with the rom you posted here. It stays on the boot logo indefinitely. After a clean install and making sure it boots fine once, I'm manually flashing the boot.img in the zip and copying the contents of the modules dir while fixing permissions afterwards. Is that all there is to it or am I missing something?
Click to expand...
Click to collapse
You just extracting all files from camera fix, then update cm13.0 flashable zip with files from camera fix and flash flashable zip. It worked on Temasek's CM13. I'll do more researches and inform about results.
alexander_32 said:
You just extracting all files from camera fix, then update cm13.0 flashable zip with files from camera fix and flash flashable zip. It worked on Temasek's CM13. I'll do more researches and inform about results.
Click to expand...
Click to collapse
Ah, I read the OP wrong and wasn't merging into the rom zip but manually into existing installation. Though even now, I still can't boot after trying it with plain cm13, beanstalk, or temasek. I'm using twrp 2.8.7.0 with cache and data both f2fs if that makes any difference.
Has anyone else had success so far and if so with which roms?
r3t3ch said:
Ah, I read the OP wrong and wasn't merging into the rom zip but manually into existing installation. Though even now, I still can't boot after trying it with plain cm13, beanstalk, or temasek. I'm using twrp 2.8.7.0 with cache and data both f2fs if that makes any difference.
Has anyone else had success so far and if so with which roms?
Click to expand...
Click to collapse
I guess now I understand what happened. I flashed my fix first, then did factory reset and flashed changed zip. I'll test it and inform what happened
CONFIRMED: It's 3.0.72+ kernel.
http://i66.tinypic.com/33mwkyw.png
http://i64.tinypic.com/33u8qow.png
CONFIRMED: PAC ROM MM works!
http://i66.tinypic.com/2n8v5uf.png
CONFIRMED: Cyanogenmod works!
http://i64.tinypic.com/2eunbz9.png
CONFIRMED: BeanStalk works! (Solution was a kernel from RR 5.6.5 with blue logo)
http://i67.tinypic.com/107rwx2.png
alexander_32 said:
UNBELIEVABLE! It works on Temasek only! But I'm not done yet. Need some time to think.
Confirmed: It's 3.0.72+ kernel.
http://i66.tinypic.com/33mwkyw.png
http://i64.tinypic.com/33u8qow.png
I'll update this thread with more information.
Click to expand...
Click to collapse
I'm thinking it doesn't work on transi's RR or CM13 builds because he disabled the camera with some commits that he hasn't pushed to GitHub. Either way, those builds are built with 3.0.101+, and the patches you brought in are from 3.0.72+. It would make sense if they didn't boot after patching (especially if you flash the boot.img). What happens if you just replace the files in /system and leave the boot image intact?
monster1612 said:
I'm thinking it doesn't work on transi's RR or CM13 builds because he disabled the camera with some commits that he hasn't pushed to GitHub. Either way, those builds are built with 3.0.101+, and the patches you brought in are from 3.0.72+. It would make sense if they didn't boot after patching (especially if you flash the boot.img). What happens if you just replace the files in /system and leave the boot image intact?
Click to expand...
Click to collapse
My builds work with 3.0.101+ as well, but Temasek's works and BeanStalk doesn't (with 3.0.72+). Yes, I'll try it.
monster1612 said:
I'm thinking it doesn't work on transi's RR or CM13 builds because he disabled the camera with some commits that he hasn't pushed to GitHub. Either way, those builds are built with 3.0.101+, and the patches you brought in are from 3.0.72+. It would make sense if they didn't boot after patching (especially if you flash the boot.img). What happens if you just replace the files in /system and leave the boot image intact?
Click to expand...
Click to collapse
I tried that yesterday, and it results in never getting to the boot animation, so the kernel never loads.
5 from 7 for today. A new link https://www.androidfilehost.com/?fid=24591000424949408
Dear XDA Community,
Sorry, this is a newbie question, but when I was asking for suggestions for a custom and also secure ROM, I was suggested Pixel Experience and I have also been told to set SELinux to permissive. What is the purpose of SELinux? Is there a guide on how to adjust it to the appropriate settings? Does it not come enabled as default? Thank you in advance.
jason.mix said:
Dear XDA Community,
Sorry, this is a newbie question, but when I was asking for suggestions for a custom and also secure ROM, I was suggested Pixel Experience and I have also been told to set SELinux to permissive. What is the purpose of SELinux? Is there a guide on how to adjust it to the appropriate settings? Does it not come enabled as default? Thank you in advance.
Click to expand...
Click to collapse
SELinux policy is a security feature built into your kernel. Android is set to "enforcing" by default, you have to manually switch to permissive. A lot of custom mods and root enabled apps require your device to be in permissive mode in order to work. A classic example that I've used many times is a mod called Viper4Android, it requires permissive mode in order for it to function. This is not the only example, there are many other apps and mods that require permissive mode. Your device must be rooted in order to use permissive mode.
There is nothing special about enabling this, you just need to look for a custom kernel for your specific model number that has permissive mode built into the kernel then install the kernel or you can find an app such as SELinux Switch/SELinux Toggle, but, I'm not sure if that app is supported any more, the developer that built it hasn't been active here in quite some time.
Sent from my SM-S767VL using Tapatalk
Droidriven said:
SELinux policy is a security feature built into your kernel. Android is set to "enforcing" by default, you have to manually switch to permissive.
Click to expand...
Click to collapse
Thank you for your response. Just to clarify, should I just leave it as it comes or should I always double check after flashing the custom ROM? And is there a guide on how to adjust this option appropriately or does it depend on the ROM? I came across this thread and it states that Pixel Experience is set to permissive automatically. What should I do? And do you have any other advice for what other precautions I should take in order to have that extra security when using a custom ROM? Once again, thank you.
jason.mix said:
Thank you for your response. Just to clarify, should I just leave it as it comes or should I always double check after flashing the custom ROM? And is there a guide on how to adjust this option appropriately or does it depend on the ROM? I came across this thread and it states that Pixel Experience is set to permissive automatically. What should I do? And do you have any other advice for what other precautions I should take in order to have that extra security when using a custom ROM? Once again, thank you.
Click to expand...
Click to collapse
If you are concerned with being secure, you need to leave the device in enforcing mode, not permissive. I'm not sure exactly how you would switch the Pixel ROM from permissive to enforcing, the ROM may have a setting or you may have to use the Kernel Auditor app to switch to enforcing mode.
If you are not going to be doing any kind of modification to the system partition, you won't need to worry with permissive mode.
If the Pixel ROM is permissive by default, you won't need to change anything.
I'm not sure you understand exactly how the "switch" between enforcing/permissive is achieved. It not simply a "setting" that you enable/disable.
Here are a few ways to enable permissive mode that I know of:
1) if your stock kernel does not support permissive mode, you have to flash a kernel that has permissive support.
2) if your stock kernel does support permissive mode but doesn't have permissive mode enabled, you have to use something like the "SELinux Switch" or "SELinux Toggle" apps, these apps force the stock kernel into permissive mode and can be set to automatically enable permissive mode whenever the device boots and persist from one reboot to the next.
3) it can be enabled via adb commands or adb shell commands via PC or, if you are rooted, you can use a terminal emulator app or the terminal emulator that is built into TWRP to issue commands to enable enforcing/permissive, whichever you need.
Sent from my SM-S767VL using Tapatalk
Droidriven said:
If you are concerned with being secure, you need to leave the device in enforcing mode, not permissive. I'm not sure exactly how you would switch the Pixel ROM from permissive to enforcing, the ROM may have a setting or you may have to use the Kernel Auditor app to switch to enforcing mode.
Click to expand...
Click to collapse
I am not planning on rooting or modifying my system in any way, but is there a way to check whether I am running in enforcing mode? I am still running MIUI for now and if it helps, my kernel version is 4.9 186-perf-g1e22c7b and if you need any more details then just let me know. Thank you for helping me out.
jason.mix said:
I am not planning on rooting or modifying my system in any way, but is there a way to check whether I am running in enforcing mode? I am still running MIUI for now and if it helps, my kernel version is 4.9 186-perf-g1e22c7b and if you need any more details then just let me know. Thank you for helping me out.
Click to expand...
Click to collapse
To check whether your device is set to enforcing/permissive, you should be able to look in system settings>about phone>SELinux Status
Or
system settings>about phone>software info>SELinux Status
Or something similar, the exact location of the info is different for different devices/android versions.
Sent from my SM-S767VL using Tapatalk