Hi,
I have been trying to get omnirom to work for the Galaxy Mega 6.3, but its stuck in bootanimation. The first build I tried worked, but none of the build that I compiled this month worked.
The logcat shows displayeventreceiver / activedisplay errors mainly.
Code:
E/DisplayEventReceiver( 890): Display event receiver pipe was closed or an error occurred. events=0x9
E/FlpHardwareProvider( 890): Error hw_get_module 'flp': -2
W/InputDispatcher( 890): channel '418a3790 ActiveDisplayView (server)' ~ Consumer closed input channel or an error occurred. events=0x9
E/InputDispatcher( 890): channel '418a3790 ActiveDisplayView (server)' ~ Channel is unrecoverably broken and will be disposed!
W/InputDispatcher( 890): channel '418ac6b8 StatusBar (server)' ~ Consumer closed input channel or an error occurred. events=0x9
E/InputDispatcher( 890): channel '418ac6b8 StatusBar (server)' ~ Channel is unrecoverably broken and will be disposed!
Can someone help me?
The massive amount of null fd spam should've been obvious as the root problem, although admittedly how to solve it isn't entirely obvious. (to be honest, needs to be in the wiki...)
https://github.com/omnirom/android_...mmit/4c5fbe5354eab42eaf33927d0c245bc9632a3cae
You'll need to clobber after revering that aosp frankendisplay commit
Thanks @Entropy512!!!!
Got it to boot. Now next issue. No touchscreen input. Any inputs to sort that.
Obviously got the same problem with my build for Nexus S here...
ROM does not boot or booted once and can't be rebooted anymore (stuck in boot loop) Attached 'reboot' parts of logcat... No idea at the moment where the problem is. All my builds worked fine before. Last working build was created at 5.th of February...
Solved. There seems to be a Problem with the new bootanimation for some devices. Just remove it or exchange with old one...
Gesendet von meinem Nexus S mit Tapatalk
lagloose said:
Solved. There seems to be a Problem with the new bootanimation for some devices. Just remove it or exchange with old one...
Gesendet von meinem Nexus S mit Tapatalk
Click to expand...
Click to collapse
ok that's WEIRD
OK. Solved all but one issue. HW decoder.
There is a fix in the works so that low-memory devices can have the flashy, new boot animation and not crash.
https://gerrit.omnirom.org/#/c/5597/
---
Posted from whatever phone booted today
Related
/* Info */
There's a known issue on Android 5.0 Lollipop.
The bootanimation binary(/system/bin/bootanimation - Responsible for initial boot animations during bootup) causes a serious memory leak, too exhaustive that core system services or other processes can be killed during boot,
or on the worst case, endless boot loop due to core system services unable to initialize.
/* Why? */
My theory is, the current bootanimation implementation does not releases the resources held to play previous frames.
Testing this on a Galaxy S4 with a 1080p bootanimation.zip file resulted in 200MB of RAM usage in 3 seconds, and the kernel starts to kill processes in 10 seconds.
With a Nexus 7, luckily, it did pass on the bootanimation and showed up the lock-screen. However, some services got killed during boot and resulted in an overall unstable system.
I've been able to reproduce this bug on majority of devices including Galaxy Note 3, Galaxy S4, Nexus 7, Nexus 5, Nexus 4 and much more with CyanogenMod 12, Google's pure/stock AOSP and LG's Lollipop firmware.
I'm almost certain that other Android 5.0 Lollipop ROMs may have the same problem(except for Samsung's Touchwiz - Touchwiz uses qmg format and I was unable to reproduce this bug on Touchwiz).
You maybe asking yourself -
"But CM12 has this issue solved?"
Short answer is no, they've just put a band-aid on it - reducing framerate and clearing up caches more aggressively to "workaround", and this is not a permanent solution.
"What about other manufacturer's ROM?"
On my test, Samsung's Touchwiz was the only ROM that has this issue solved(probably thanks to the their proprietary qmg format). Other manufacturers - LG, hTC and more - may also suffer from the same bug.
"Can I expect this fix to be integrated with CyanogenMod 12 nightlies?"
Maybe. I've sent this fix to CyanogenMod Gerrit code review. If they approve it, it'll be integrated into future nightly builds.
/* Solution? */
Before I could have come up with a permanent solution, I suggested users to remove /system/bin/bootanimation from their devices for now, as this is a very serious issue.
Now, I've got a working, permanent fix.
V2 - Much cleaner code & misc fixes with some bootanimation.zip files
The attached "bootanimation.zip" contains 3 binaries.
cm12/bootanimation is for CyanogenMod 12(or its fork) users
aosp/<CPU architecture>/bootanimation is for pure/stock AOSP(or its fork) users & manufacturer's ROM users & Nexus users with stock ROM installed.
<You must install the right bootanimation binary for your device's CPU architecture; users will most likely install 32bit unless they use Nexus 9 or LG G flex 2>
Download the "bootanimation.zip", extract the right "bootanimation" binary and put it under /system/bin - replacing the old one.
The correct owner is root:root,
the correct permission is 755(rwxr-xr-x).
If those binaries do not work for you, I'm afraid your ROM developer/builder have to integrate the fix into the source code, or not use the bootanimation at all
/* Some more technical information */
If you're a ROM developer, who wants to integrate this fix, please read below and cherry-pick the correct fix.
Android Issue tracker - https://code.google.com/p/android/issues/detail?id=140061
CyanogenMod Gerrit code review - http://review.cyanogenmod.org/88968
CyanogenMod Gerrit GitHub - https://github.com/CyanogenMod/andr...mmit/de11ae6610f3c96b07b8e2e1d0dc1531c21ac82f
Android Gerrit code review - https://android-review.googlesource.com/132681
Reserved
Reserved
My thanks limit is 8 thanks per day so I am typing Thanks here I will press thanks button tomorrow
Good I go to test thank bro
Added to my Temasek CM12 BUILD v6.8!!
Thanks
How we that we use stock LG rom can fix this bug???
arter97 said:
/* Info */
There's a known issue on Android 5.0 Lollipop.
The bootanimation binary(/system/bin/bootanimation - Responsible for initial boot animations during bootup) causes a serious memory leak, too exhaustive that core system services or other processes can be killed during boot,
or on the worst case, endless boot loop due to core system services unable to initialize.
/* Why? */
My theory is, the current bootanimation implementation does not releases the resources held to play previous frames.
Testing this on a Galaxy S4 with a 1080p bootanimation.zip file resulted in 200MB of RAM usage in 3 seconds, and the kernel starts to kill processes in 10 seconds.
With a Nexus 7, luckily, it did pass on the bootanimation and showed up the lock-screen. However, some services got killed during boot and resulted in an overall unstable system.
I've been able to reproduce this bug on majority of devices including Galaxy Note 3, Galaxy S4, Nexus 7, Nexus 5, Nexus 4 and much more with CyanogenMod 12, Google's pure/stock AOSP and LG's Lollipop firmware.
I'm almost certain that other Android 5.0 Lollipop ROMs may have the same problem(except for Samsung's Touchwiz - Touchwiz uses qmg format and I was unable to reproduce this bug on Touchwiz).
You maybe asking yourself -
"But CM12 has this issue solved?"
Short answer is no, they've just put a band-aid on it - reducing framerate and clearing up caches more aggressively to "workaround", and this is not a permanent solution.
"What about other manufacturer's ROM?"
On my test, Samsung's Touchwiz was the only ROM that has this issue solved(probably thanks to the their proprietary qmg format). Other manufacturers - LG, hTC and more - may also suffer from the same bug.
"Can I expect this fix to be integrated with CyanogenMod 12 nightlies?"
Maybe. I've sent this fix to CyanogenMod Gerrit code review. If they approve it, it'll be integrated into future nightly builds.
/* Solution? */
Before I could have come up with a permanent solution, I suggested users to remove /system/bin/bootanimation from their devices for now, as this is a very serious issue.
Now, I've got a working, permanent fix.
The attached "bootanimation.zip" contains 3 binaries.
cm12/bootanimation is for CyanogenMod 12(or its fork) users
aosp/<CPU architecture>/bootanimation is for pure/stock AOSP(or its fork) users & manufacturer's ROM users & Nexus users with stock ROM installed.
<You must install the right bootanimation binary for your device's CPU architecture; users will most likely install 32bit unless they use Nexus 9 or LG G flex 2>
Download the "bootanimation.zip", extract the right "bootanimation" binary and put it under /system/bin - replacing the old one.
The correct owner is root:root,
the correct permission is 755(rwxr-xr-x).
If those binaries do not work for you, I'm afraid your ROM developer/builder have to integrate the fix into the source code, or not use the bootanimation at all
/* Some more technical information */
If you're a ROM developer, who wants to integrate this fix, please read below and cherry-pick the correct fix.
Android Issue tracker - https://code.google.com/p/android/issues/detail?id=140061
CyanogenMod Gerrit code review - http://review.cyanogenmod.org/88918
CyanogenMod Gerrit GitHub - https://github.com/CyanogenMod/andr...mmit/6b0cabc4d0a131800bd7ff75f0653e4c0cd7d3a4
Android Gerrit code review - https://android-review.googlesource.com/132562
Click to expand...
Click to collapse
Explains why my new CM12 flashes end up in a bootloop.
I have a Nexus 6. How would I know if I have this problem?
Is there an easy way I can check if this works?
I mean, my phone still boots fine, but I expected to see the sudden frame drops to be gone, but they're still here...
how about using the lollipop bootanim on the older android version like kk. do I need to do the same fix as well ? show me the light please
If this is because Google is using its AnimationDrawable for the bootanimation, then it's part of the half-ass SDK Google is still putting out.
AnimationDrawable loads ALL frames and never releases previous-frames during playback until the entire drawable is unloaded.
You would think after GIF, MPEG, MNG or APNG (animated PNG), SVG, etc, Google wouldn't go back to pre-school raw-frame animations.
edit: looking at the actual patch, that animation GL animation code from Google is pretty bad. Generating a new texture id per frame is stupid, and using only one texture otherwise, is just as bad. It should be 2, or 3 texture ids reused continuously in a ring-buffer, and that's it.
So, removing the GL code at lines 786-791 is bad because it's generating a texture for all the frames that are coming up. Dropping that means it drops all the frames that was going to get used.
Deleting lines 837-841 causes a texture memory id leak, though no texture-memory leak due to lines 786-791 being deleted. I'd agree with comment https://code.google.com/p/android/issues/detail?id=140061#c6
The way "Animation" on line 608 is used, it looks very much like an AnimationDrawable. So this whole thing is typical of Google not having coders that can do proper animation code.
sweet find bro!
arter97 said:
/* Info */
/* Why? */
My theory is, the current bootanimation implementation does not releases the resources held to play previous frames.
Click to expand...
Click to collapse
As long as the loaded frames get reused, this makes a lot of sense, doesn't it?
It's faster to display the frame from memory than to load it again.
As long as the boot animation doesn't get overly large, which it usually doesn't do, this should not be an issue.
Or do I miss something here?
domenukk said:
As long as the loaded frames get reused, this makes a lot of sense, doesn't it?
It's faster to display the frame from memory than to load it again.
As long as the boot animation doesn't get overly large, which it usually doesn't do, this should not be an issue.
Or do I miss something here?
Click to expand...
Click to collapse
https://code.google.com/p/android/issues/detail?id=140061
See before(#7) and after(#8).
The differences are HUGE and #7 is definitely an issue
arter97 said:
/* Info */
There's a known issue on Android 5.0 Lollipop.
The bootanimation binary(/system/bin/bootanimation - Responsible for initial boot animations during bootup) causes a serious memory leak, too exhaustive that core system services or other processes can be killed during boot,
or on the worst case, endless boot loop due to core system services unable to initialize.
.....
/* Some more technical information */
If you're a ROM developer, who wants to integrate this fix, please read below and cherry-pick the correct fix.
Android Issue tracker - https://code.google.com/p/android/issues/detail?id=140061
CyanogenMod Gerrit code review - http://review.cyanogenmod.org/88968
CyanogenMod Gerrit GitHub - https://github.com/CyanogenMod/andr...mmit/de11ae6610f3c96b07b8e2e1d0dc1531c21ac82f
Android Gerrit code review - https://android-review.googlesource.com/132681
Click to expand...
Click to collapse
Thanks man! If I get around to building ROMs I'll include this patch for sure!
arter97 said:
https://code.google.com/p/android/issues/detail?id=140061
See before(#7) and after(#8).
The differences are HUGE and #7 is definitely an issue
Click to expand...
Click to collapse
Sorry, didn't read this earlier. Good find if true.
NuShrike said:
If this is because Google is using its AnimationDrawable for the bootanimation, then it's part of the half-ass SDK Google is still putting out.
AnimationDrawable loads ALL frames and never releases previous-frames during playback until the entire drawable is unloaded.
You would think after GIF, MPEG, MNG or APNG (animated PNG), SVG, etc, Google wouldn't go back to pre-school raw-frame animations.
edit: looking at the actual patch, that animation GL animation code from Google is pretty bad. Generating a new texture id per frame is stupid, and using only one texture otherwise, is just as bad. It should be 2, or 3 texture ids reused continuously in a ring-buffer, and that's it.
So, removing the GL code at lines 786-791 is bad because it's generating a texture for all the frames that are coming up. Dropping that means it drops all the frames that was going to get used.
Deleting lines 837-841 causes a texture memory id leak, though no texture-memory leak due to lines 786-791 being deleted.
Click to expand...
Click to collapse
I'm not a OpenGL expert, I've just messed around the code to find out how to fix it "apparently".
You may wanna go read comments here https://code.google.com/p/android/issues/detail?id=140061 (especially #7 and #8).
Can you come up with a better patch?
I guess I'll cherry-pick this tonight, why not.
We also need this revert, correct? https://android-review.googlesource.com/#/c/132680/1
take note for change owner must be;
0 - root & group 2000 - shell
There is no problem with LG firmware
@arter97 I own a LG G3 updated to latest Lollipop firmware from LG(i.e. official firmware) , and I assure you that this bug has been fixed by LG and everything is working as it should , no bootloops or anything in the normal usage is buggy.
Good morning guys,
I just started my long way to try to port Mer to the Sony Xperia M2... But I just got stuck at a point I can't even re-sync my sources anymore.
Code:
HABUILD_SDK [eagle] [email protected]:~$ repo sync --fetch-submodules
error: in `sync --fetch-submodules`: revision refs/tags/android-5.1.1_r1 in platform/prebuilts/clang/linux-x86/3.1 not found
I'm using THIS SOURCES, which are the ones used to build CM12.1 for my device as Galaxyfreak (who is working very hard on CM12.1 for M2) told me. In CM12.1 there are no bugs, BTW.
What do you guys think, is a problem with this sources or do I need to reset my git?
Hi there.
I'm using OmniROM 20150520 (the final) on my N7000.
Some time ago I faced with problem: when I try to set wallpaper to lockscreen, after wallpaper chosen and cropping action expected, I'm getting message like "application "com.android.wallpapercropper" error".
Which could a reason of the problem be?
I'm using OmniROM a long time. Had no mentioned bug on prevoius versions and on the final one first time also. For now reinstallation of the firmware and dalvik's wipe give no results.
demonx993x said:
Hi there.
I'm using OmniROM 20150520 (the final) on my N7000.
Some time ago I faced with problem: when I try to set wallpaper to lockscreen, after wallpaper chosen and cropping action expected, I'm getting message like "application "com.android.wallpapercropper" error".
Which could a reason of the problem be?
I'm using OmniROM a long time. Had no mentioned bug on prevoius versions and on the final one first time also. For now reinstallation of the firmware and dalvik's wipe give no results.
Click to expand...
Click to collapse
Not sure... N7000 has been abandoned for a long time, it was basically coasting on inertia for months. As the device no longer has a maintainer, nothing is going to get fixed.
Entropy512 said:
Not sure... N7000 has been abandoned for a long time, it was basically coasting on inertia for months. As the device no longer has a maintainer, nothing is going to get fixed.
Click to expand...
Click to collapse
Thanks Entropy512, I'm sure you are right. BTW, I saw only one new Android mod (based on CM12.1) for N7000, but it has no direct attention to Omni.
Nevertheless, it seems, the mentioned issue is not linked with FW own bugs because there was no problems first time after installation.
Suppose, the issue could be linked with errors of file system, or paths and permissions, or even third party software influence (unlikely).
I couldn't find algorithm of wallpapercropper work (where does it place current lockscreen wall files, how should them be named, which system files/properties does it change and to which files/folders should it have permissions) to try fixing manually.
Could you help me with this?
There is log of wallpapercropper operation, where errors appear, below (gotten by Catlog SW)
build.board: smdk4210
build.bootloader: unknown
build.brand: samsung
build.cpu_abi: armeabi-v7a
build.cpu_abi2: armeabi
build.device: n7000
build.display: omni_n7000-userdebug 4.4.4 KTU84P 560 test-keys
build.fingerprint: samsung/omni_n7000/n7000:4.4.4/KTU84P/560:userdebug/test-keys
build.hardware: smdk4210
build.host: devbox.omnirom.org
build.id: KTU84P
build.manufacturer: Samsung
build.model: GT-N7000
build.product: omni_n7000
build.radio: unknown
build.serial: 001a7a0708dc9e
build.tags: test-keys
build.time: 1432164566000
build.type: userdebug
build.user: jenkins
version.codename: REL
version.incremental: 560
version.release: 4.4.4
version.sdk_int: 19
11-12 21:49:32.698 I/ActivityManager(2362): START u0 {cmp=com.android.wallpapercropper/.LockscreenWallpaper} from pid 6093
11-12 21:49:32.923 I/ActivityManager(2362): Displayed com.android.wallpapercropper/.LockscreenWallpaper: +205ms
11-12 21:49:53.498 E/MediaStore(6148): at com.android.wallpapercropper.LockscreenWallpaper.cropImage(LockscreenWallpaper.java:232)
11-12 21:49:53.498 E/MediaStore(6148): at com.android.wallpapercropper.LockscreenWallpaper.onActivityResult(LockscreenWallpaper.java:343)
11-12 21:49:53.563 E/AndroidRuntime(6148): Process: com.android.wallpapercropper, PID: 6148
11-12 21:49:53.563 E/AndroidRuntime(6148): java.lang.RuntimeException: Failure delivering result ResultInfo{who=null, request=1024, result=-1, data=Intent { dat=content://media/external/images/media/92730 flg=0x1 }} to activity {com.android.wallpapercropper/com.android.wallpapercropper.LockscreenWallpaper}: java.lang.NullPointerException: uriString
11-12 21:49:53.563 E/AndroidRuntime(6148): at com.android.wallpapercropper.LockscreenWallpaper.cropImage(LockscreenWallpaper.java:233)
11-12 21:49:53.563 E/AndroidRuntime(6148): at com.android.wallpapercropper.LockscreenWallpaper.onActivityResult(LockscreenWallpaper.java:343)
11-12 21:49:53.568 W/ActivityManager(2362): Force finishing activity com.android.wallpapercropper/.LockscreenWallpaper
11-12 21:49:54.068 W/ActivityManager(2362): Activity pause timeout for ActivityRecord{421b9250 u0 com.android.wallpapercropper/.LockscreenWallpaper t9 f}
11-12 21:49:55.778 I/WindowState(2362): WIN DEATH: Window{42191228 u0 com.android.wallpapercropper/com.android.wallpapercropper.LockscreenWallpaper}
11-12 21:49:55.778 I/ActivityManager(2362): Process com.android.wallpapercropper (pid 6148) has died.
Hello everyone, is there some info for me?
Hi there, still no any info?
I already gave you all the info you're going to get (unless you fix this yourself) in my last post - no one is maintaining this device any more and has not for over two years now, so it's not going to get fixed.
Entropy512 said:
I already gave you all the info you're going to get (unless you fix this yourself) in my last post - no one is maintaining this device any more and has not for over two years now, so it's not going to get fixed.
Click to expand...
Click to collapse
I just hoped someone could clarify java exceptions).
Introduction
Work in progress CyanogenMod 13.0 for jactivelte (Samsung Galaxy S 4 Active I9295). I maintain this as well i can afford time to so so, so don't expect perfect rom anytime soon. Development ended
Code:
/*
* Your warranty is now void.
*
* I'm not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*
*/
Features
Luuk up CyanogenMod 13.0 in the net. This ROM is just a build of current CM13 sources, with support added for jactivelte. In future, optimizations might be added.
Bugs
A lot, probably. But what i know:
no SIM detected
exfat sdcard support seems to be broken
camera is probably as broken as it is with CM12.1
other stuff? You tell me
Release notes
20151223
first build
Downloads
https://drive.google.com/folderview?id=0BzJzDM42pkRvOG1aZ2lxTVpyUHc&usp=sharing
XDA:DevDB Information
CM13.0, ROM for the Samsung Galaxy S 4 Active
Contributors
spegelius
Source Code: https://github.com/spegelius
ROM OS Version: 6.0.x Marshmallow
Version Information
Status: No Longer Updated
Created 2015-12-24
Last Updated 2016-04-27
Nice to see someone still interseted with this ! wish i could test it but having my phones digitizer dead , i cant taste marshmallow yet
@spegelius: thank you so much for showing love to our good old jactivelte!
Gesendet von meinem GT-I9295 mit Tapatalk
New build, cm-13.0-20151225_182928-UNOFFICIAL-jactivelte, uploading. Just repo sync and this one should work with multirom
Really good work. Whit multirom i can test, even if the best will be whit functional sim of course. ?
Send from somewhere... or not?
Just for understanding: why is sim and exfat broken? Couldnt we use the s4 source-tree as the hardware is identical in most parts? Or is it broken, too? Sorry, maybe a am thinking too simple as a am no developer
Gesendet von meinem GT-I9295 mit Tapatalk
moviecut said:
Just for understanding: why is sim and exfat broken? Couldnt we use the s4 source-tree as the hardware is identical in most parts? Or is it broken, too? Sorry, maybe a am thinking too simple as a am no developer
Gesendet von meinem GT-I9295 mit Tapatalk
Click to expand...
Click to collapse
Source tree and vendor props are same as in regular S4, which makes me think that maybe jactive's bootloader or modem is somehow different... i'm flashing newest Samsung rom to see if updating modems and whatever else helps with that. If not, then use ril stuff from CM12.1.
As for exfat, maybe it's not implemented yet? I think this was the case with CM12 also, exfat took some time to get implemented as it needs extra libs and packages.
Did someone already tried to flash a modem for s4? How high are the chances, that it will brick a s4 active? Maybe that is the key to a working sim?
Gesendet von meinem GT-I9295 mit Tapatalk
moviecut said:
Did someone already tried to flash a modem for s4? How high are the chances, that it will brick a s4 active? Maybe that is the key to a working sim?
Gesendet von meinem GT-I9295 mit Tapatalk
Click to expand...
Click to collapse
I tried flashing S4 modems at some point, like a year ago and as i recall, it's not even possible to flash them. Some kind of checksum fails and flashing fails before actually flashing the file. This was with Heimdall so i don't know what Odin does. If the checksum check is done on receiving end, then it doesn't matter what flasher is used.
Edit: oh and i flashed latest available Samsung rom, I9295XXUDOI5_I9295TIMDOI1_TIM.zip. No change with CM13 RIL, no SIM detected. But ran into problems with TWRP, it started failing due to selinux declining recovery access to lots of things, had to compile new TWRP with selinux in permissive mode...
I also reverted some vendor blobs to CM12.1 state, but no help. I took a logcat and noticed that selinux was denying access to binaries related to RIL... needs more investigation.
Well it seems flashing OI5 was a mistake, since now CM13 won't boot without using adb shell to set selinux to permissive mode... i'll need to see if i can downgrade somehow.
Downgraded to OB4, at least i think i did. I flashed aboot.mbn, modem.bin, NON-HLOS.bin, rpm.mbn, sbl1.mbn, sbl2.mbn, sbl3.mbn and tz.mbn (sbl1.mbn is from NK4 rom as OB4 doesn't have that file). No change, my phone simply refuses to boot all of the CM13 builds because selinux denies stuff. On the other hand, CM12.1 and SlimLP beta 10 work fine, so something weird is going on with CM13...
I did manage to hack round it by adding more options for installd to sepolicy, but i feel that this is something shouldn't need to do. I'm going to revert /data back to ext4, hopefully it's just unfinished support for f2fs in CM13. If so, i'll stick with ext4, f2fs has brought only more trouble so far than any improvements.
I also managed to debug RIL problem, first it was missing vendor props and after that some permission problem, might be related to above problem with my phone...
Thanks for keeping us up-to-date, spegelius!
Gesendet von meinem GT-I9295 mit Tapatalk
Is it possible to try SlimLP beta 10 please!?
quubee said:
Is it possible to try SlimLP beta 10 please!?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=64577511&postcount=67
the major issue is no sim detected of course thats a big deal for everyone. wifi works fine browsing youtube ok. NFC never used in my s4 active so dont know. if sim card detected i will definetly used as my daily driver battery life seems good when compare with the cm12.1 officials. BIG THANKS TO THE spegelius still looking for the s4 active. thanksssssssss
My external sd it's not detected, or better, cannot mount.
I think that this cause some problem whit apps like music or file manager that are stucked and don't run. Others app work fine.
Send from somewhere... or not?
Alright, ril problem figured out: selinux denies access to qmux radio socket. Fixed it by setting selinux to permissive on boot for now (same as S4 CM13 i think), so take this into consideration, bad apps can do bad things possibly.
Uploading now:
cm-13.0-20160101_224952-UNOFFICIAL-jactivelte
set selinux to permissive mode
RIL should be working now
few minor tweaks added
repo synced 1.1.2016
Exfat still doesn't work, reason is that vold doesn't support exfat yet; but as CM development goes, features come at some point.
Wow latest buid looks to me OK LTE, cellular calls even my SD card detects. camera works flawless Setting menu crashed 1 time other than anything bugs didn't noticed so far in 3 hours. Thanks for great job spegelius
what gapps do you use? Will this package work: www.opengapps.org/ (arm / android 6.0 / pico)
Gesendet von meinem GT-I9295 mit Tapatalk
moviecut said:
what gapps do you use? Will this package work: www.opengapps.org/ (arm / android 6.0 / pico)
Gesendet von meinem GT-I9295 mit Tapatalk
Click to expand...
Click to collapse
Here is the download link
http://highonandroid.com/download-android-6-0-marshmallow-gapps/
Hello,
I'm opening this thread to provide some info about a bug introduced in the nougat releases.
Since 7.0 first release build-in VPN client is broken, any connection end with an error under the menu entry, without any traffic goingout of the device.
Logcat shows a link error un the racoon binary (responsible of ipsec connections):
Code:
12-11 10:16:19.669 3496 3496 F libc : CANNOT LINK EXECUTABLE "/system/bin/racoon": cannot locate symbol "DES_is_weak_key" referenced by "/system/bin/racoon"...
12-11 10:16:19.669 3496 3496 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 3496 (racoon)
12-11 10:16:19.725 3497 3497 F DEBUG : pid: 3496, tid: 3496, name: racoon >>> /system/bin/racoon <<<
This feature was working in LP/MM, but is broken since first N release. Digging a bit into the MM libs looks like the symbol "DES_is_weak_key" was in the dynamic table of libWVStreamControlAPI_L3.so library (which is missing in N):
Code:
$ ./aarch64-linux-android-objdump -T /mnt/vendor/lib/libWVStreamControlAPI_L3.so | grep DES_is_weak_key
0019b9ac g DF .text 00000028 Base DES_is_weak_key
Hope this helps to develop a fix in next updates.
Best regards,
Hello magamo79,
thank you for providing these infos. That is probably the best bug report, we have ever got .
We are using an older racoon binary in vendor which is wrong. I already made a bigger cleanup on s3 plus (which also removes this binary from vendor so that it gets build from source). This change is missing in s3 repos. We will work on merging them in the next days. Then this error will also be fixed.
Short correction: DES_is_weak_key isn't defined by libWVStreamControlAPI_L3. It is only used in libWVStreamControlAPI_L3 and racoon. This symbol got defined by openssl which isn't used in android anymore.
Cheers
Hi again,
The VPN error is fixed in that last build (Build [7.1.1] 20170105 - Stable 6). Great Job @fire855 & Team :good:
Best regards,