Related
I own my SGS i9000 now for 2 years and since I've acquired it, until this day, I can not find a call recording app that actually works, correctly.
(Do note a correctly working "call recorder", not a "voice recorder", and not a solution recording from the mic)
Call recording is not outlawed within my country and surely there are many more owners who'd like to record sales calls from call centres as those calls form the entire contract.
(Though one is informed that the call is being recorded, have you actually tried acquiring a copy of those recordings, for your own records, from the call centres .... ?? - Personally I'd rather watch paint dry as that would be more exciting and much less frustrating )
The only solution seems to have your side recorded as well, which seems to be the eluding holy grail of all that is Android.
What just does not make sense is how my previous Nokia did it with the click of a button and with excellent recording quality ...
.... numerous app downloaded later...
.... I ended up rooting the SGS i9000 ... as that was apparently required to make it work ,,,
.... then started flashing with custom ROMs .... all to no avail.
XDA's superior reputation within the Android community has had all my hopes on http://forum.xda-developers.com/showthread.php?t=967297 ...
which I've tried, though update_autocallrecording_main_pkg_0.3-ANT.zip simply replies with the error: "E:Error in /emmc/update_autocall" as can be see by the attached screenshot.
Currently my SGS details are a follows:
Model: GT-I9000
Android Version: 4.1.2
Baseband Version: I9000XXJVT
Kernel Version: 3.0.43-00928-g6fa96b6-dirty Devil3_1.6.1_Jelly_Helly_i9000_CFS_BLN_CMC #910
CyanogenMod Version: helly_bean_i9000
Build Number: cm_galaxysmtd-userdebug 4.12 JZ054K eng.dominik.20121015.1454444 test-keys
Is there possibly an updated update_autocallrecording_main_pkg_0.3-ANT.zip package, that I'd require ?
As I'm lost in Android Space, having no outlook on ever getting there, I place all my XDA faith upon someone whom could assist on how to get call recording working correctly on the SGS ... hopefully including the Galaxy Tab 2 10.1
Is there honestly not a single Galaxy S i9000 user that would love to have call recording ?
Hope is not all gone...you have a status 0 error, in other words, just extract the zip you are trying to flash, then replace the update-binary (inside META-INF folder) from another working zip...then rezip the files...you will be able to flash it but one thing, it may not necessary work...
Ryuinferno thanks for the info.
Is my understanding correct that **any** zip will do ?
Be it an OTA update .zip (i.e. GT-P5100_P5100XXCLI3-OTA-P5100XXBLH4_DBT_295452894.zip) or app .zip (i.e. CWM-SuperSU-v0.96.zip)
Will it make any impact as I've updated all my devices to either (un)official Jelly OTA or truly custom (Helly) Jelly ROM's ?
It is ok as long as you take the updater binary from any zip that works on your phone...
===============================================================
Issue closed, read:
http://forum.xda-developers.com/showpost.php?p=42638124&postcount=17
===============================================================
l2_hsic issue
l2_hsic running amok (GT-P7500, GT-P7501) is ONE considerable reason for abnormal battery drain.
The so far known counter measures (HC, Stiffmeister + its xda derivate, WiFi-ROM) do not comply to my requests:
- CM10.1 nightlies
- 3G usage
- no l2_hsic hassle
l2_hsic root cause
Analysis of kmsg files provide a consistent pattern. Function if_usb_suspend(..) from modem_link_device_hsic.c does not call wake_lock_timeout(..) in wakelock.c in case of l2_hsic is running amok.
The missed call to wake_lock_timeout is obviously caused by a non cancellable USB-connection.
It is a single non expiring wakelock, what makes trouble.
Inside of modem_link_device_hsic.c I lost track on further explanations.
Candidate to fix the issue
Since I cannot correct the root cause, I tried to fix its consequence.
Basis is the current pershoot P4 CM10.1 kernel.
There are a few spots in its source code, where one could obtain the so called prevent_suspend_time of a l2_hsic wakelock.
A monitor is installed in such place. It triggers, when a l2_hsic wakelock’s individual prevent_suspend_time exceeds >10s (empirical value).
In this case the function wake_lock_timeout is called, which ignites the wakelock’s expiration.
Next the trigger is reset and the monitoring becomes active again.
As a second and measure of last resort the tab is shutdown, once l2_hsic’s total prevent_suspend_time exceeds >1h (never happened so far).
All these events are logged:
--> /proc/grzwolf shows current status
--> /proc/kmsg is extended by a couple of messages
Verification
The described modified kernel was installed on my Tab months ago.
Since then DS works perfect to me.
Furthermore I did not experience any side effects.
This kernel-mod had been announced at
http://www.android-hilfe.de/samsung...s-10-1n-mit-stock-4-0-4-a-69.html#post5550736
Meanwhile the kernelmod is integrated:
BeeGee(Ganbarou), AAccount(A1 Kernel), kasper_h(Team Infamous/AOKP) and twa_priv(CM10.1/SGT7)
Preconditions for installation
- the kernelmod applies only for P4 devices (GT-P7500, GT-P7501)
- no need to contiue, if you don’t have a l2_hsic issue
- if you continue, you should know what you are doing
- I don’t take any warranty
- after flashing a Nightly ROM, the kernelmod needs to be installed again
- CM10.1 is installed on P4 according to the OP of thread http://forum.xda-developers.com/showpost.php?p=36077123&postcount=1
Kernelmod installation
- comply to the preconditions above
- within CWM make a Nandroid backup of a running isntallation
- copy 'P4 kernel' (see downloads below) to your Tab
- install 'P4 kernel modified' within CWM and check functionality after booting up
- if not ok, restore in CWM your Nandroid backup
Credits
- pershoot (Kernel)
- MapleSyrup (Kernel build)
- nakedninja42 (CM10.1 Installation)
Changelog
Rev. 2013.04.10-19.44
first release
Downloads
- CWM flashable kernel zip, Rev. 2013.04.10-19.44
- md5 sum of kernel zip
- source code
- readme source code
All hail grzwolf! Thank you so freaking much for finally finding the fix that no one could. I now don't need to flash a WiFi ROM to get rid of the l2_hsic issue.
Sent from my GT-P7500 using XDA Premium HD app
Great work, grzwolf!
Did you find the root cause of the wakelock based on your extended logging?
Is it OK for you if I take your code, streamline it a bit (remove logging, renaming methods, ...) and integrate it in the CM kernel?
C-o-M said:
Great work, grzwolf!
Did you find the root cause of the wakelock based on your extended logging?
Is it OK for you if I take your code, streamline it a bit (remove logging, renaming methods, ...) and integrate it in the CM kernel?
Click to expand...
Click to collapse
Root Cause
According to my current testing (next revision kernelmod), I'm almost convinced it's caused by a race condition
between modem and modem interface (most likely the "kill_urb stuff").
Just by adding the extended logging in "if_usb_suspend" seem to have wiped the issue with the missing "wake_lock_timeout".
As next I'm going to switch back to the erroneous behaviour, verifying this theory.
If this approach would stand, the extended logging could be replaced by reasonable delays.
Not impossible, that the whole silly detection & triggering in wakelock.c is not needed.
Usage
That would be fine to me, so no problems at all with code re use.
You mean the issue is fixed by just adding some delays in if_usb_suspend? So you do not enter your wake lock fix at all with the current patch?
C-o-M said:
You mean the issue is fixed by just adding some delays in if_usb_suspend? So you do not enter your wake lock fix at all with the current patch?
Click to expand...
Click to collapse
That's what I'm currently trying out.
I would never had come up with this assumption, without the wish to understand the logic behind.
Since the nature of this presumable race condition is a fickle ***** (if my assumption is correct),
it may take a while to have solid evidence.
Although, it sounds tempting.
Thank YOU!!!
Thanks for this fix grzwolf, works as it should. Now my P7500 is great with cm10.1 and good battery life. :good:
theone
Question ! Do i have to flash source code or just only p4_kernel_2013.04.10-19.44.zip ? Thanks
saigon66 said:
Question ! Do i have to flash source code or just only p4_kernel_2013.04.10-19.44.zip ? Thanks
Click to expand...
Click to collapse
Just the one you mentioned --> p4_kernel_2013.04.10-19.44.zip
CHN Kernel
grzwolf said:
Just the one you mentioned --> p4_kernel_2013.04.10-19.44.zip
Click to expand...
Click to collapse
Since the Chinese Kernel solo, solves the problem why don't you compare the kernels. Hope i'm not ofending you with probably a stupid question. I'm saying this because when i found Stifmeister zip file and solution, i installed the chinese kernel directly via odin, and just overwrited some network files (i presume), and since then, 8 months ago, never seen a wakelock and a battery drain. Some my humble assumption was that the Chinese Kernel has no l2_hsic wakelock, except, when you connect a USB sd card and unmount it without passing through settings.
Hope it helps.
PS: I should have said this first, i'm still on stock...
Great Job anyway..
Thanks
Phibs said:
Since the Chinese Kernel solo, solves the problem why don't you compare the kernels. Hope i'm not ofending you with probably a stupid question. I'm saying this because when i found Stifmeister zip file and solution, i installed the chinese kernel directly via odin, and just overwrited some network files (i presume), and since then, 8 months ago, never seen a wakelock and a battery drain. Some my humble assumption was that the Chinese Kernel has no l2_hsic wakelock, except, when you connect a USB sd card and unmount it without passing through settings.
Hope it helps.
PS: I should have said this first, i'm still on stock...
Great Job anyway..
Thanks
Click to expand...
Click to collapse
Your suggestion is absolutely conclusive and would be definitely worth a follow up.
Afaik only Samsung knows, what sources and settings were used to build this specific Chinese Kernel,
Means, they are very unlikely available. Otherwise the magic would have been unveiled long time ago.
I suppose disassembling the kernel and looking for the specific code where the wakelock is set would be too difficult?
Sent from my GT-P7100 using Tapatalk 4 Beta
doctorow said:
I suppose disassembling the kernel and looking for the specific code where the wakelock is set would be too difficult?
Sent from my GT-P7100 using Tapatalk 4 Beta
Click to expand...
Click to collapse
At least for me.
Afaik it would end up with machine code / assembler language.
Another tool were required to translate it into C.
Even then, there were no really meaningful function and variable names.
Means, one couldn't easily compare this with existing sources.
Finally the whole exercise could result in already known source code.
Not impossible, that the "magic of the China-Kernel" is caused by very specific compiler or optimization settings, which cannot reverse engineered.
Too many if and may be ...
Comparing kernel sources is a very good idea.
Pershoot's p4 kernel is based on Samsungs kernel sources for GT-P7510, Opensource Update 2, released in April 2012 (AFAIR).
For the p5 kernel, I always rebased pershoot's kernel to the latest sources (to GT-P7300_HK_ICS_Opensource_Update1.zip in September, to GT-P7300_ICS_Opensource_Update1.zip in December). No one has ever reported the l2_hsic bug on CM for p5. Neither on CM10 (where I used the chinese kernel sources), nor on CM10.1 (updated to the official ICS sources). But the bug occured for example on AAcount's kernel which isn't rebased. So Samsung seems to fixed the issue in the kernel instead of doing some "magic hacks".
I commited a lot of different p4/p5 kernels to github to make it easier to compare them. I guess you'd like to take a look on those changes:https://github.com/cmorlok/android_kernel_samsung_p5/tree/P7300_ICS_U1/drivers/misc/modem_if
Great, of course I would. Thanks.
Just kdiffed modem_link_device_hsic from your recent P5 against P4, there are non trivial differences.
I'll give it a try right away.
hi c-o-m and grzwolf.
can you please furnish the latest code to this implementation?
any SOD as a result? any other weird behavior?
i'd like to get this in to mainline, if no issue.
thx
pershoot said:
hi c-o-m and grzwolf.
can you please furnish the latest code to this implementation?
any SOD as a result? any other weird behavior?
i'd like to get this in to mainline, if no issue.
thx
Click to expand...
Click to collapse
Following C-o-M's advise with the code review between P4 and P5 modem interface was the breakthru.
The P5 modem interface has a number of non trivial changes compared to its P4 counterpart (--> git format-patch attached).
Although I didn't understand the details, I gave them a try and replaced the P4 modem interface from your github repo completely with the one coming from P5.
Non of the usual test cases made any problem regarding l2_hsic or anything else.
- long time operation
- charging w/o reboot
- USB-drive operation
- Wifi
- 3G
Currently I'm on the 20130604 CM nightly + KernelMod, means 12 days in sequence since last reboot.
BTW: Neither a single SOD, nor any other weird behavior.
To my opinion, the l2_hsic amok issue could be finally closed.
Hail to C-o-M.
Do you think this will get merged into where ever it is that the cm team get their kernals from?
grzwolf said:
Following C-o-M's advise with the code review between P4 and P5 modem interface was the breakthru.
The P5 modem interface has a number of non trivial changes compared to its P4 counterpart (--> git format-patch attached).
Although I didn't understand the details, I gave them a try and replaced the P4 modem interface from your github repo completely with the one coming from P5.
Non of the usual test cases made any problem regarding l2_hsic or anything else.
- long time operation
- charging w/o reboot
- USB-drive operation
- Wifi
- 3G
Currently I'm on the 20130604 CM nightly + KernelMod, means 12 days in sequence since last reboot.
BTW: Neither a single SOD, nor any other weird behavior.
To my opinion, the l2_hsic amok issue could be finally closed.
Hail to C-o-M.
Click to expand...
Click to collapse
cool thx grzwolf.
Lol, shows how much I pay attention. I completely missed pershoots post.
Edit:
Ok, looks like this should be in the nightlies now....
http://forum.xda-developers.com/showpost.php?p=42680093&postcount=1875
Apologies for the links: as I am a new user, I am not allowed to directly link to outside sources. Please replace _ with :// or . (Forum suggestion: use optional pre-publication review for posts from new users that depend strongly on external links.)
INTRODUCTION: My BMW 318 (E46, 2004) had a factory default BMW ULF bluetooth module (early generation) that worked fine with my BB Q10 and all phones up to Android 4.1. From 4.2 onwards, I and many others have been having problems with keeping the Bluetooth connection alive for more than a few seconds. This has been widely reported but never addressed in stock Android. As even the latest OTA upgrade to 4.4.3 didn't solve it, I decided to compile the required Bluetooth kernel module myself.
BACKGROUND: The change from the Bluez to Bluedroid system in Android 4.2 caused the compatibility issues. User 'wulu' at the forums of CyanogenMod reported on how he patched his CM10.2 (and later) to include a patch that solves the issue. I repeated his procedure for stock 4.4.3 for the Nexus 5.
Markus Schmidt's problem description & patch: https_github_com/Root-Box/external_bluetooth_bluedroid/commit/97d2f6346bad56299f60cfcd8c45ad893a0da78c
Wulu's specifics for Nexus 5 & BMW's ULF for CM: http_forum_cyanogenmod_com/topic/77834-bluetooth-connection-drops-car-kit-bmw/
METHODS:
The following procedure is specifically to compiled the Bluetooth kernel module for the Nexus 5 hardware and the 4.4.3_r1.1 (OTA) release. It should therefore only work for this specific combination. If you want to compile the module yourself, please read the linked pages with Google's excellent instructions: http_source_android_com/source/initializing.html
Here are a couple of notes I made that deal with some specifics for my Mac and the Nexus 5:
On Mountain Lion (Mac), I had to use Xcode 5.0.2 to get past a compile error. See instructions here on how to download and use the older 5.0.2 version of Xcode: https_groups_google_com/forum/#!topic/android-building/FPCSo1xKJ4U
Do not download the "master" source using the repo command, but download "android-4.4.3_r1.1". The master source has post-OTA changes that make a compiled module incompatible with the OTA release for the Nexus 5. "android-4.4.3_r1.1" was listed on those pages as specifically the version that was used for the OTA 4.4.3 upgrade for the Nexus 5.
Setup the environment as instructed and add the three proprietary driver sets listed for the Nexus 5 and 4.4.3 (see "Building for devices" on the Google pages).
There is no need to use the full patch. You can make the two small modifications to the bta_ag_sdp.c file using any text editor. Find the file first (find . -name "bta_ag_sdp.c") and commend out the two lines with the minus signs given in wulu's the first post (or Markus Schmidt's patch) by putting a # in front of both lines: #if (p_scb->peer_features == 0), #p_scb->peer_features = p_attr->attr_value.v.u16;.
Select the "aosp_hammerhead-userdebug" (=Nexus 5) option with the lunch command, and compile using the make command. I was able to follow the instructions pretty much to the letter without any problems.
After the compilation I had two version of the file, in four locations. They are easily found using the find command (find . -name "bluetooth.default.so" -exec ls -la {} \. The bigger one (in the symbols subdirectory) is for debugging. The smaller one is the one I used (and which is linked in this message). It was located at "./out/target/product/hammerhead/system/lib/hw/bluetooth.default.so" in my source tree.
After this, it was pretty straightforward. I rooted my Nexus 5, re-installed FX (with paid-for Root add-on, but the free ES File Explorer should also work), uploaded the file via Dropbox and its Save to SD, transferred it to the R/W mounted system directory to replace /system/lib/hw/bluetooth.default.so with it, and restarted my phone. I also modified the config file (/system/etc/bluetooth/auto_pair_devlist.conf) that blacklists BMW components by commenting out most lines, but I am not sure if this is helpful or not.
RESULTS: It seems a little bit less stable than the Bluetooth connection I had with my Blackberry, but it definitely works. I was able to transfer my contacts and to make and receive calls. For anybody with stock KitKat 4.4.3 on the Nexus 5, here is the bluetooth.default.so kernel module: http_s000_tinyupload_com/index.php?file_id=07750725920558658087
DISCUSSION: The compilation procedure can undoubtedly be optimized. I compiled the entire source tree over several hours, just to be sure I didn't miss out on things. Feel free to give tips, but I'm happy that it worked at all.
CONCLUSION: Thanks to wulu's advice in the CM forum thread I was able to compile a patched Bluetooth module for stock Android with KitKat 4.4.3 that works with my BMW 318 (E46, 2004) ULF car kit.
That´s great! :good:
Is it possible for you to provide the same for Nexus 5 - 4.4.4 OTA ?
mnasty said:
That´s great! :good:
Is it possible for you to provide the same for Nexus 5 - 4.4.4 OTA ?
Click to expand...
Click to collapse
Yes, great job!
Nobody have already done this for 4.4.4 ? I'll do this if I have time.
ZeroKcm said:
Yes, great job!
Nobody have already done this for 4.4.4 ? I'll do this if I have time.
Click to expand...
Click to collapse
4.4.4 from 4.4.3 is only security fixes, everything else is the same.
Does 5.0 Lollipop resolve the BMW ULF connection issue?
guys, do you think 5.0 Lollipop would resolve the current BMW ULF connection problem? Have anyone tried the 5.0 yet ?
I'm still in 4.4.3 working great on N5 paring ULF 8th Gen kit, thanks for S1010, wulu and Alpejohn guiding me the entire process.
REV HRD said:
guys, do you think 5.0 Lollipop would resolve the current BMW ULF connection problem? Have anyone tried the 5.0 yet ?
I'm still in 4.4.3 working great on N5 paring ULF 8th Gen kit, thanks for S1010, wulu and Alpejohn guiding me the entire process.
Click to expand...
Click to collapse
I have the same disconnect issue with my Seat, haven't tried the fix cause I was running 4.4.4 and there was no ready module for it, but lollipop didn't fixed it. I tried compilation without success. I followed all the instructions and compiled it successfully, but after replacing it, bluetooth fails to start. In the logcat logs I can see that it complains there is no bluetooth (something like that, don't have the exact logs to check it now), seems the compiled so file is not compatible.
If anyone can give a hand on this
Not sure if Seat using the same implementation as BMW ULF kit provides, my family also has a 06 Audi A4 with stock BT, I don't experience any connection issue from the stock 4.4.3 on N5. I would think Audi / Seat might use the same BT module as they share most of the VW parts.
I experience the same disconnects. I was experiencing it and with the old phone Galaxy Nexus, till one day I updated to cyanogenmod and the problem was gone. Then changed the phone with Nexus5 and again I have the same issues, tried everything with no luck. Changing the kernel, doing some stuff with paid bluetooth apps to manage the phonebook that the car is accessing. So I suspect the problem is the same
(Seems I'm still not able to post links, I just prepared one with the Blutooth device model number and year on it, if it mean anything to someone it is from 03.2007).
Don't work in lollipop, in your free time please compile a new file.
Thks.
S1010 said:
Apologies for the links: as I am a new user, I am not allowed to directly link to outside sources. Please replace _ with :// or . (Forum suggestion: use optional pre-publication review for posts from new users that depend strongly on external links.)
INTRODUCTION: My BMW 318 (E46, 2004) had a factory default BMW ULF bluetooth module (early generation) that worked fine with my BB Q10 and all phones up to Android 4.1. From 4.2 onwards, I and many others have been having problems with keeping the Bluetooth connection alive for more than a few seconds. This has been widely reported but never addressed in stock Android. As even the latest OTA upgrade to 4.4.3 didn't solve it, I decided to compile the required Bluetooth kernel module myself.
BACKGROUND: The change from the Bluez to Bluedroid system in Android 4.2 caused the compatibility issues. User 'wulu' at the forums of CyanogenMod reported on how he patched his CM10.2 (and later) to include a patch that solves the issue. I repeated his procedure for stock 4.4.3 for the Nexus 5.
Markus Schmidt's problem description & patch: https_github_com/Root-Box/external_bluetooth_bluedroid/commit/97d2f6346bad56299f60cfcd8c45ad893a0da78c
Wulu's specifics for Nexus 5 & BMW's ULF for CM: http_forum_cyanogenmod_com/topic/77834-bluetooth-connection-drops-car-kit-bmw/
METHODS:
The following procedure is specifically to compiled the Bluetooth kernel module for the Nexus 5 hardware and the 4.4.3_r1.1 (OTA) release. It should therefore only work for this specific combination. If you want to compile the module yourself, please read the linked pages with Google's excellent instructions: http_source_android_com/source/initializing.html
Here are a couple of notes I made that deal with some specifics for my Mac and the Nexus 5:
On Mountain Lion (Mac), I had to use Xcode 5.0.2 to get past a compile error. See instructions here on how to download and use the older 5.0.2 version of Xcode: https_groups_google_com/forum/#!topic/android-building/FPCSo1xKJ4U
Do not download the "master" source using the repo command, but download "android-4.4.3_r1.1". The master source has post-OTA changes that make a compiled module incompatible with the OTA release for the Nexus 5. "android-4.4.3_r1.1" was listed on those pages as specifically the version that was used for the OTA 4.4.3 upgrade for the Nexus 5.
Setup the environment as instructed and add the three proprietary driver sets listed for the Nexus 5 and 4.4.3 (see "Building for devices" on the Google pages).
There is no need to use the full patch. You can make the two small modifications to the bta_ag_sdp.c file using any text editor. Find the file first (find . -name "bta_ag_sdp.c") and commend out the two lines with the minus signs given in wulu's the first post (or Markus Schmidt's patch) by putting a # in front of both lines: #if (p_scb->peer_features == 0), #p_scb->peer_features = p_attr->attr_value.v.u16;.
Select the "aosp_hammerhead-userdebug" (=Nexus 5) option with the lunch command, and compile using the make command. I was able to follow the instructions pretty much to the letter without any problems.
After the compilation I had two version of the file, in four locations. They are easily found using the find command (find . -name "bluetooth.default.so" -exec ls -la {} \. The bigger one (in the symbols subdirectory) is for debugging. The smaller one is the one I used (and which is linked in this message). It was located at "./out/target/product/hammerhead/system/lib/hw/bluetooth.default.so" in my source tree.
After this, it was pretty straightforward. I rooted my Nexus 5, re-installed FX (with paid-for Root add-on, but the free ES File Explorer should also work), uploaded the file via Dropbox and its Save to SD, transferred it to the R/W mounted system directory to replace /system/lib/hw/bluetooth.default.so with it, and restarted my phone. I also modified the config file (/system/etc/bluetooth/auto_pair_devlist.conf) that blacklists BMW components by commenting out most lines, but I am not sure if this is helpful or not.
RESULTS: It seems a little bit less stable than the Bluetooth connection I had with my Blackberry, but it definitely works. I was able to transfer my contacts and to make and receive calls. For anybody with stock KitKat 4.4.3 on the Nexus 5, here is the bluetooth.default.so kernel module: http_s000_tinyupload_com/index.php?file_id=07750725920558658087
DISCUSSION: The compilation procedure can undoubtedly be optimized. I compiled the entire source tree over several hours, just to be sure I didn't miss out on things. Feel free to give tips, but I'm happy that it worked at all.
CONCLUSION: Thanks to wulu's advice in the CM forum thread I was able to compile a patched Bluetooth module for stock Android with KitKat 4.4.3 that works with my BMW 318 (E46, 2004) ULF car kit.
Click to expand...
Click to collapse
FYI, had similar issue with 2009 E61 5 series. Solution was third party app (Bluetooth Phone book) and a full software update for the car from the dealer. The app cost a few quid, the dealer software update much more!
That said, it works perfectly with stock Lollipop and I consider it money well spent.
---------- Post added at 09:15 PM ---------- Previous post was at 09:13 PM ----------
FYI, it was this app: https://play.google.com/store/apps/details?id=com.android_rsap.irmc
BASIC KERNEL
Features:
knox removal
adb insecure
selinux permissive
init.d support
busybox
frandom
ntfs rw support with app
PRO KERNEL
Features:
knox removal
adb insecure
selinux permissive
init.d support
busybox
frandom
ntfs rw support with app
synapse support (installs with kernel)
cpu oc/uv support
gpu oc/gpu support
battery tweaks
network tweaks
... and much more
This branch is mainly based on skyhigh kernel (@UpInTheAir)
PRO-VTFB KERNEL
The same as pro branch with vt and fb enabled support.
if doubt, do not use it.
note: booting is longer as usual
CHANGELOG:
v1.3:
- optimization and performance tweaks
v1.2:
- Synced with SkyHigh kernel 1.9
DOWNLOAD
Basic branch v1.0 https://yadi.sk/d/IYF-XNCGbbrPh
Pro branch v1.3 https://yadi.sk/d/SKdK47o1bwJTT
Pro-vtfb branch 1.3 https://yadi.sk/d/XbwusUz8bwJUQ
CREDITS
UpInTheAir, xluco, halaszk88, AndreiLux and many others
SOURCE CODE
https://github.com/bonuzzz/kernel_p900
Great a lot of people have been waiting for this will flash and test it out later tonight
Thanks for your work! Great to see more people with the right knowledge with their hands on a Note Pro.
Unfortunately I use the camera daily....I'll keep an eye on this, though, in case that gets worked out.
ExtremeRyno said:
Thanks for your work! Great to see more people with the right knowledge with their hands on a Note Pro.
Unfortunately I use the camera daily....I'll keep an eye on this, though, in case that gets worked out.
Click to expand...
Click to collapse
I'm a retired deveopler and don't mind helping out a little where I can. I've enjoyed tweaking my P900 to the max & I'm also glad to finally see some stuff coming out here on XDA for the P900 wifi version. Not much activity on any other forum for this device either. Most likely because of the price of the device and people worring about the Knox tripping issue. I noticed on another forum that someone had compiled a fully functional kernel however they too were experiencing issues with the camera. Anybody have any ideas of whats causing the camera issue? I can possibly help out with the developement of a AOSP rom, or a blazing fast slimmed down ROM. I have plenty of developement knowledge in this area, if there are any interest for one. As for the Kernel issues I'm not too familiar with the compiling however most likely could figure it out.
Developers don't need no stinkin' signature!
If I've been able to help you, please hit the "Thanks" button.
Flashed this kernel and my tablet won't boot
golfinggino said:
Flashed this kernel and my tablet won't boot
Click to expand...
Click to collapse
? I hope you made a backup of your stock kernel before flashing...
Has anyone else flashed this kernel and can confirm if it is booting or not?
Developers don't need no stinkin' signature!
If I've been able to help you, please hit the "Thanks" button.
I started from scratch and flashed the tweaked p900 rom and this kernel and now it is working great it seems to be much quicker then what it was I really appreciate your work and it makes this tablet what it should be
golfinggino said:
I started from scratch and flashed the tweaked p900 rom and this kernel and now it is working great it seems to be much quicker then what it was I really appreciate your work and it makes this tablet what it should be
Click to expand...
Click to collapse
Can you describe what happens when you select the "Camera" application. Does it force close, not launch, display some type of error. If you could provide the details of what happens, it may be possible to provide a working solution or "Work around."
Also, try installing another camera application from the Android Market and see if that application works. Maybe using another camera source will work and that could be a temporary work around till the issue us resolved. Let us know. Thanks!
Developers don't need no stinkin' signature!
If I've been able to help you, please hit the "Thanks" button.
Mine says warning camera failed
golfinggino said:
Mine says warning camera failed
Click to expand...
Click to collapse
Ok, Thanks. We'll see if we can figure this thing out...
Did you try installing another camera app from the play store and see what happens when you launch it?
Developers don't need no stinkin' signature!
If I've been able to help you, please hit the "Thanks" button.
here's my observations:
1. Samsung Knox does not get removed as claimed in OP
2. Knox FC every time something is installed and uninstalled (likely under different circumstances too)
3. front camera works perfectly fine
4. rear camera does indeed fail
5. Google camera and 3rd party camera apps fail too
6. Z Device Test still detects all the hardware properties of the rear camera (but maybe that info is retrieved from elsewhere in the /system)
7a. all logcat apps do not work. i waited about 3 to 4 minutes for each to load.
7b. I haven't used it on this tab in a long time so I don't know if kernel caused this
7c. yes, I granted SU to the logcat apps, and later verified that SU wasn't denied.
my relevant info:
p900 USA wifi-only 64gb model
P900UEU1ANC5 (XAR)
edit:
to anyone that cannot boot after installing:
1. try wiping cache and dalvik cache
2. re download and try again if above doesn't fix it
3. if above doesn't fix it and you're on NAE, try updating to ANC5 (or newer?) THEN flashing the kernel again
4. if you're on a version newer than ANC5 that might be the problem and you are out of luck until the kernel is updated for it.
don't ask me about how to update, that's your burden
Sterist said:
here's my observations:
1. Samsung Knox does not get removed as claimed in OP
2. Knox FC every time something is installed and uninstalled (likely under different circumstances too)
3. front camera works perfectly fine
4. rear camera does indeed fail
5. Google camera and 3rd party camera apps fail too
6. Z Device Test still detects all the hardware properties of the rear camera (but maybe that info is retrieved from elsewhere in the /system)
7a. all logcat apps do not work. i waited about 3 to 4 minutes for each to load.
7b. I haven't used it on this tab in a long time so I don't know if kernel caused this
7c. yes, I granted SU to the logcat apps, and later verified that SU wasn't denied.
my relevant info:
p900 USA wifi-only 64gb model
P900UEU1ANC5 (XAR)
edit:
to anyone that cannot boot after installing:
1. try wiping cache and dalvik cache
2. re download and try again if above doesn't fix it
3. if above doesn't fix it and you're on NAE, try updating to ANC5 (or newer?) THEN flashing the kernel again
4. if you're on a version newer than ANC5 that might be the problem and you are out of luck until the kernel is updated for it.
don't ask me about how to update, that's your burden
Click to expand...
Click to collapse
thanks for you post
indeed knox doesn't fully uninstall. i forgot two apks to delete.
what program do you test front camera? it is very helpful info to resolve problem
also i have problem with ntfs mount. i will solve on next update.
flashlight doesn't work
bonuzzz said:
thanks for you post
indeed knox doesn't fully uninstall. i forgot two apks to delete.
what program do you test front camera? it is very helpful info to resolve problem
also i have problem with ntfs mount. i will solve on next update.
Click to expand...
Click to collapse
stock, Google camera, and Z Device Test
edit: flashlight does work for me
edit #2: with stock, you can't get to front camera again after switching to rear, because the app will just close when the rear fails. mine was already on front, then I switched to rear and
Sterist said:
stock, Google camera, and Z Device Test
edit: flashlight does work for me
edit #2: with stock, you can't get to front camera again after switching to rear, because the app will just close when the rear fails. mine was already on front, then I switched to rear and
Click to expand...
Click to collapse
i think there is problem with permissions but i can't find where is exactly
bonuzzz said:
i think there is problem with permissions but i can't find where is exactly
Click to expand...
Click to collapse
probably SElinux
Sterist said:
probably SElinux
Click to expand...
Click to collapse
it's permissive
and camera works in stock kernel with selinux permissive.
z device test sees two cameras, so it doesn't kernel problem. back camera and flashlight dont work for me. front camera works fine. i dont have any ideas except permissions
if anyone want to help, this is a kernel without any mods https://yadi.sk/d/-RWbv8htbYW28
ps: replaced link above. logcat is working here
bonuzzz said:
it's permissive
and camera works in stock kernel with selinux permissive.
z device test sees two cameras, so it doesn't kernel problem. back camera and flashlight dont work for me. front camera works fine. i dont have any ideas except permissions
Click to expand...
Click to collapse
that might be the app not able to turn on this tab's LED
torch apps work
Okay, this has nothing to do with me since I have P905 with stock kernel. I just read this thread by curiosity and though one thing about camera. Can you open test menu anyway on that device which opens on 3G models (and phones) by typing *#0*# to dialer (P900 has no dialer right?) There you can perform some tests to device and one is to check does camera work right.
Hope this helps, or then it wont
Spere said:
Okay, this has nothing to do with me since I have P905 with stock kernel. I just read this thread by curiosity and though one thing about camera. Can you open test menu anyway on that device which opens on 3G models (and phones) by typing *#0*# to dialer (P900 has no dialer right?) There you can perform some tests to device and one is to check does camera work right.
Hope this helps, or then it wont
Click to expand...
Click to collapse
p900 doesn't have dialer
z device test detects both cameras..
i now realize why it seems much faster - i am running with interactive and fiops and it is contantly at 2000mhz no lower frequencies are being used - i though it was like this on performance not interactive - obviously the battery is not great right now lol
Make this pretty later
You just made my day
Sent from my Nexus 6
I just confused myself. Should i be flashing the bootloader, radio, etc from a nexus factory image and then flash omni? I have been using 20150605 build without doing this. Should i do this for the nightlies?
subterfugium said:
Code:
I:operation_start: 'Flashing'
Installing '/sdcard/Download/omni-5.1.1-20150623-shamu-NIGHTLY.zip'...
Checking for MD5 file...
MD5 matched
Verifying zip signature...
I:read key e=3 hash=20
I:1 key(s) loaded from /res/keys
I:comment is 1477 bytes; signature 1459 bytes from end
I:failed to verify against RSA key 0
E:failed to verify whole-file signature
E:Zip signature verification failed: 1
Error flashing zip '/sdcard/Download/omni-5.1.1-20150623-shamu-NIGHTLY.zip'
I guess zip verification fails because of test-keys or what does that zip verification stand for?
Click to expand...
Click to collapse
Honestly, I've never used zip verification for all the years I've been flashing ROMs and have never had any issues.
I'm probably wrong but.. My theory is that packed somewhere inside the zip you are trying to flash lies a key, which is compared next a second key once extracted. If they don't match it throws an error and aborts the operation.
Sent from my Nexus 6 using XDA Free mobile app
I've never used zip verification for this exact reason, and therefore have never looked into it. This sounds like something for the TWRP thread that @Dees_Troy could answer maybe.
Does anyone have a rundown of what this Rom has to offer beyond stock aosp? The Rom OP is a bit bare of info. Thanks
The Rom OP is a bit bare of info. Thanks
530farm said:
Does anyone have a rundown of what this Rom has to offer beyond stock aosp? The Rom OP is a bit bare of info. Thanks
Click to expand...
Click to collapse
Off the top of my head... battery icon customization, volume match orientation, volume wake, screenshot delete, advanced reboot menu, hide usb debugging icon, ambient display customization. Also, Omni is the only AOSP ROM where I don't get force closes when taking multiple HDR+ pictures in a row without pause.
Completely stable device functionality with whatever you see on gerrit :good:
I will make a "features list" tomorrow
I saw that the past few builds uploaded were all 0mb. Just wondering what's going on until the builds resume?
Gandalf said:
Completely stable device functionality with whatever you see on gerrit :good:
I will make a "features list" tomorrow
Click to expand...
Click to collapse
Not sure if feature requests are allowed or not, if not then just ignore this..
But I was wondering if the 5 second home button delay on app launchers (such as Swipepad) is something that may be removed? That'd make navigating the phone much quicker for those of us who do use app launchers.
I saw opendelta mentioned in the main thread but I haven't seen any indication it exists within the ROM. Am I just missing it?
Ngo93 said:
Not sure if feature requests are allowed or not, if not then just ignore this..
But I was wondering if the 5 second home button delay on app launchers (such as Swipepad) is something that may be removed? That'd make navigating the phone much quicker for those of us who do use app launchers.
Click to expand...
Click to collapse
jira.omnirom.org :good:
glockliberty said:
I saw opendelta mentioned in the main thread but I haven't seen any indication it exists within the ROM. Am I just missing it?
Click to expand...
Click to collapse
Updates to opendelta have not been merged yet
I am certainly interested in giving OmniRom a try. A couple of questions...
First, I'm attempting to download the Omni 5.1.1 20150725 Nightly (newest as of this writing) and the download is going exceptionally slow (20-30KB/s) on the official dl.omnirom.org mirror. Is there an issue with the server at current or an up to date mirror?
Next, is there an overall feature list for Omni (on Nexus 6)? Many ROMs place a list of their main features as well as any other ROMs/kernels they incorporate (ie based on CyanogenMod 12.1, with latest CM12.1 commits added on every update etc..)).
Thank you!
RanceJustice said:
I am certainly interested in giving OmniRom a try. A couple of questions...
First, I'm attempting to download the Omni 5.1.1 20150725 Nightly (newest as of this writing) and the download is going exceptionally slow (20-30KB/s) on the official dl.omnirom.org mirror. Is there an issue with the server at current or an up to date mirror?
Next, is there an overall feature list for Omni (on Nexus 6)? Many ROMs place a list of their main features as well as any other ROMs/kernels they incorporate (ie based on CyanogenMod 12.1, with latest CM12.1 commits added on every update etc..)).
Thank you!
Click to expand...
Click to collapse
The server is probably being slow. They just upgraded storage/cleaned it up a few days ago and it has been significantly faster, it might be your connection to the server or something else.
As far as a list of features, there isn't one to my knowledge but you can certainly check on gerrit to see what's been merged recently. Just flash it and see for yourself: highfive:
Does this rom have layers?
Omnirom 5.1.1 nightly sudden reboot+supersu freeze+bluetooth headset bugs
I installed Omnirom 3days ago and have to say; nice stuff. runs fluid, batterie's fine and overall i like user experience. BUT
I'm experiencing some bugs.
first of all sometimes there just are random sudden reboots. On stock rom this happened from time to time when battery was below 30% or something so i thought there has to be a powersaving feature or something in kernel that don't works correct.
Then i flashed TWRP+Omnirom and those sudden reboots started happening randomly; regardless of battery.
I googled and found that could be some setting that adapt display brightness(???) and/or some apps bugging/conflicting. and, from previous experience, i know that this could also be a hardware/battery failure(please not; can't send my phone back right now as i need it daily for work and my N5 has a broken touch )
i tried disabling that display feature and also installed and tested if 'Lux' has any impact on that as it, basically, does the same but no change.
i factory reseted my device multiple times and tried to find out what APP could force this but... right now there's only the bare minimum(contacts+ / messages+ / aquamail / maildroid / todoist /calengoo /business calender pro and google stock apps)and still same problem. sometimes even while calling what's very embarassing when having an important customer on phone ...
I gonna try Zen Kernel next just to see if different kernel with different cpu scheduler COULD make any difference.
Then the second bug is my bluetooth headset(Plantronics M165). Can't get it to pair. Before Omnirom this worked very well as it should. Now, most of time he finds nothing and sometimes he finds a mac address of the headset but not the name. Other bluetooth devices are working fine and the headset's still working perfectly well on my gf's HTC M8. Anyone any ideas?
Last bug i experienced is SuperSU. Always an app needs root i can't get SuperSU intercept my choice. I click on allow or deny but nothing happens and after 10seconds superSu autodenies(or allows; depends on settings )right after factory reset supersu just works fine but suddenly stops working. root's still there as i can perfectly tell supersu what to do in its settings. Only the on demand root question can't be answered. uninstalling/reinstalling supersu didn't change anything. It doesn't matter if i install supersu by playstore or by zip through recovery. also unrooting and rerooting doesn't help. only a factory reset helps; for a while.
I don't want to change my Superuser managment as i paid for the pro version ...
Hope to find some help here as it's one of my fav places for everything smartphone related since back in my tytn days
so much knowledge in here.
keep up the good work
update:
sudden Reboot Problem solved, Same for superSu Problem.
just the Bluetooth problem's still there. flashing back to Stock resolves the issue but... stock and I really start liking omnirom...
anyone any ideas ?
Sent from my Nexus 6 using XDA Free mobile app
nightfly.0684 said:
update:
sudden Reboot Problem solved, Same for superSu Problem.
just the Bluetooth problem's still there. flashing back to Stock resolves the issue but... stock and I really start liking omnirom...
anyone any ideas ?
Sent from my Nexus 6 using XDA Free mobile app
Click to expand...
Click to collapse
M builds will be ready soon enough :good:
great news
Do we get the Update for M through opendelta or is a factory reset + reflash needed?
and if i understand right you assume that the Bluetooth Problem should be gone with M?
would be nice as, right now, I sometimes have to pick up important calls while driving ... and... i don't like that at all....
would try the homemade M build IF i wouldn't need it daily for work. about time to repair my n5 i guess
Sent from my Nexus 6 using XDA Free mobile app