Hi guys, find a fix for in-call audio quality for our beloved Nexus 5!
I'm using this fix for 24h now and it seems to work very well without problems.
The file is taken from the Ubuntu porting for our device.
Tested with KTU84P, should work in any other ROM, however I'm not responsible of any damage of your device, try at your own risk!
Please make a backup of file we're gonna change!
Needed
Rooted device
Root file manager
Instruction
With the file manager go to "/system/lib/hw" and copy on your sdcard partition the file "audio.primary.default.so"
Download and extract the file attached below.
With file manager replace the original "audio.primary.default.so" with downloaded one.
Change permssions of file to "rw-r--r--" THIS IS ESSENTIAL! EVEN WHEN YOU RESTORE THE ORIGINAL ONE!
Reboot and enjoy!
What problems did you have before that were fixed with flashing this file?
Well I guess I'm gonna make a backup of the original file and give this a go and report back. I had problems with call quality, either people can't hear me well, or I need to have the phone essentially glued to my ear.
Edit : Upon reboot I instantly noticed the ringing sounds marginally louder. My fiancé said she could hear me better. Too soon to tell, but I think it works. Will continue reporting back.
aeoveu said:
What problems did you have before that were fixed with flashing this file?
Click to expand...
Click to collapse
Either people can't hear me well, make a decent conversation without "i can't hear you" or "what you said? I can't understand" was very difficult. The only workaround was connect earphones
TheLastSidekick said:
Well I guess I'm gonna make a backup of the original file and give this a go and report back. I had problems with call quality, either people can't hear me well, or I need to have the phone essentially glued to my ear.
Edit : Upon reboot I instantly noticed the ringing sounds marginally louder. My fiancé said she could hear me better. Too soon to tell, but I think it works. Will continue reporting back.
Click to expand...
Click to collapse
Thanks ti give it a try! Keep me updated
Does this mean that voice recording and videos have better audio as well?
Or does it only affect calls?
alb3rtt said:
Does this mean that voice recording and videos have better audio as well?
Or does it only affect calls?
Click to expand...
Click to collapse
I didn't try but is possibile because the library manages the audio hardware, and the problem is the noise suppressor mic, that wasn't set very well. Give it a try, i recorded a video now and audio was very clean
WaxLarry said:
Hi guys, find a fix for in-call audio quality for our beloved Nexus 5!
[...]
[*]With the file manager go to "/system/lib/hw" and copy on your sdcard partition the file "audio.primary.default.so"
[...]
Click to expand...
Click to collapse
While it is a little early to dismiss this fix as placebo, there are a few things to keep in mind:
1. it is my understanding that the file audio.primary.default.so gets overruled by the device-specific file audio.primary.msm8974.so; hence it is likely that any parameter adjustments done in the "default" library get overwritten by the device-specific ("msm8974") one.
2. At least in AOSP, the source files that produce the library of this mod contain mainly no-op functions that are replaced by the functions in the files that produce the device-specific one. I have not looked at the Ubuntu source to confirm, though.
3. I believe the main issue folks are having with TX audio levels are a result of a sub-optimal (or non-optimized) dual-microphone processing algorithm.
The algorithm is buried deep inside the MSM8974 and is likely controlled via closed-source vendor blobs. It is very unlikely that open-source libraries will be able to change the parameters of the algorithm as the API's of the MSM8974 are not publicly available.
4. I just tested the proposed mod and TX level still suffers as soon as the phone is moved away from the mouth.
My guess is that folks that are reporting this mod to work are sensitive to the issues and now are holding the phones close to their mouths.
I still believe my remarks on in-call audio-quality posted here to be accurate. A true fix for this issue needs to come from either Qualcomm or LG.
chdloc said:
While it is a little early to dismiss this fix as placebo, there are a few things to keep in mind:
1. it is my understanding that the file audio.primary.default.so gets overruled by the device-specific file audio.primary.msm8974.so; hence it is likely that any parameter adjustments done in the "default" library get overwritten by the device-specific ("msm8974") one.
2. At least in AOSP, the source files that produce the library of this mod contain mainly no-op functions that are replaced by the functions in the files that produce the device-specific one. I have not looked at the Ubuntu source to confirm, though.
3. I believe the main issue folks are having with TX audio levels are a result of a sub-optimal (or non-optimized) dual-microphone processing algorithm.
The algorithm is buried deep inside the MSM8974 and is likely controlled via closed-source vendor blobs. It is very unlikely that open-source libraries will be able to change the parameters of the algorithm as the API's of the MSM8974 are not publicly available.
4. I just tested the proposed mod and TX level still suffers as soon as the phone is moved away from the mouth.
My guess is that folks that are reporting this mod to work are sensitive to the issues and now are holding the phones close to their mouths.
I still believe my remarks on in-call audio-quality posted here to be accurate. A true fix for this issue needs to come from either Qualcomm or LG.
Click to expand...
Click to collapse
Is possible that I'm wrong and this is a placebo, that were only "my" impressions, but I'm asking why in ubuntu the in-call audio quality is good if the bug is in the vendor blobs?
Does this modification increase the in-call earpiece volume at all?
WaxLarry said:
Is possible that I'm wrong and this is a placebo, that were only "my" impressions, but I'm asking why in ubuntu the in-call audio quality is good if the bug is in the vendor blobs?
Click to expand...
Click to collapse
I'm not trying to belittle your efforts. We are all better off when folks like us try to improve the experience that we are
given by Google and the hardware manufacturers. And to share our results with the greater community. That's what we are all here for.
To the point:
It is pretty easy (by modifying the build.prop) to disable dual-microphone processing and, thus, significantly improve the TX levels during a cellular call.
In fact, this has been proposed numerous times here on XDA.
However, the price one pays is that by merely changing the build.prop, other important signal processing, in particular acoustic echo cancellation,
is disabled as well.
Not having tried Ubuntu Touch on my N5 nor having looked at the source code, I suspect that dual-microphone processing is disabled in Ubuntu.
(As a matter of fact, it may even be illegal for Ubuntu to enable dual-microphone processing due to licensing issues). I also suspect that the far-end will be suffering from echoes when a phone call is made via Ubuntu. This is pure speculation and I may be completely off-base here...
chdloc said:
I'm not trying to belittle your efforts. We are all better off when folks like us try to improve the experience that we are
given by Google and the hardware manufacturers. And to share our results with the greater community. That's what we are all here for.
To the point:
It is pretty easy (by modifying the build.prop) to disable dual-microphone processing and, thus, significantly improve the TX levels during a cellular call.
In fact, this has been proposed numerous times here on XDA.
However, the price one pays is that by merely changing the build.prop, other important signal processing, in particular acoustic echo cancellation,
is disabled as well.
Not having tried Ubuntu Touch on my N5 nor having looked at the source code, I suspect that dual-microphone processing is disabled in Ubuntu.
(As a matter of fact, it may even be illegal for Ubuntu to enable dual-microphone processing due to licensing issues). I also suspect that the far-end will be suffering from echoes when a phone call is made via Ubuntu. This is pure speculation and I may be completely off-base here...
Click to expand...
Click to collapse
I know you don't want to belittle my effort, is easy to misunderstand behind a PC and for me is difficult to explain because english is not my language, so it's all ok
I don't think Ubuntu disables dual-microphone processing because there wasn't echoes during the call, there is some improvement somewhere. Before open this thread I tried to replace both audio.primary.default and audio.primary.msm8974 but many app like youtube and spotify had crash switching between speaker to headphones. When I have a bit of time I'll retry combining original "primary.default" with Ubuntu "primary.msm8974"
It is not a placebo. After a full day of calls, people can hear me fine when my mouth isn't pressed up against the phone, when before I had to have it pressed up against my mouth. I have even called 3 different people and asked if they noticed a difference and I asked if they could hear me as a I purposely moved my mouth further away from the phone
From what I'm being told they can hear me louder and clearer. I'm on T-Mobile by the way.
Sent from my Nexus 5 using Forum Fiend v1.2.11.
I too think it is an improvement! I also notice, that the voice is clearer and at least no one complained about bad quality or low volume for the time being.
Placebo or not, for me this fix is a winner but I will observe it a bit longer and report back.
Thanks for the hint! :good:
Intriguing, but it sure would be nice to know exactly what are the changes between the Ubuntu versions and the Qualcomm or LG versions.
Android L
Does this fix work with Android L?
jurquhart said:
Does this fix work with Android L?
Click to expand...
Click to collapse
So far, so good!
I'm sorry to burst everybody's bubble here, but the proposed library differs in only four bytes from the stock one, and
I believe those four bytes are related to an identifier of the build machine/process.
(I see the same four bytes differing if I compare the stock library with one that I build with AOSP 4.4.4)
I downloaded the Ubuntu source files and the only file that is needed to produce the attached library, i.e.
hardware/libhardware/modules/audio/audio_hw.c
mostly contain no-op functions.
Look, I would have loved this to work as much as anyone else, but I still maintain that this is a classic case of placebo
and/or change of usage pattern.
Related
Hallo,
I'm new to PPC and realised the scrolling and viewing of sms & mms is very slow. . Initially I thought it was normal for PPC, but my friend told me is abnormal after he view it.
Any advise please.
Good day
Most likely related to the lack of drivers for the Kaiser.... but I'm sure someboday else can confirm.
Audio said:
Most likely related to the lack of drivers for the Kaiser.... but I'm sure someboday else can confirm.
Click to expand...
Click to collapse
Mmm. And that's based on what precisely? Actually it's probably unlikely to be due to the drivers. ********* Edited for pettiness.
Some people are tending to attribute problems to video drivers and little help or thought is being put into what the real cause of problems may be.
This is the same kind of mis-information as when folk were saying the PIE scrolling was down to the drivers (and again it was unrelated to them) OR again when the speed of the camera was put down to the drivers (and again newer software shows this was not the case).
In reply to the OP. Please give us some more detail, circumstances when it happens, how slow is it, are you running any other programs concurrently etc.
Mike
ive noticed that after about 2 hours on my phone (with under 45% memory usage) my txt messages also lag. i write the entire message and it takes like 30 secounds for the message to show up for me to be able to send it. its really annoying
Obviously I'm no Kaiser Wizz, which is why I didn't say "Your problem is because of lack of drivers" (I also missed the sms bit, and thought the issue was only related to MMS, which reading again makes my first post sound insane), but thanks for being patronising in your correcting me and thanks for the mindless sheep insult (which although isn't directly poitned at me, clearly shows I'm the intended recipient).
OR again when the speed of the camera was put down to the drivers (and again newer software shows this was not the case).
Click to expand...
Click to collapse
From what I've seen this has not actually been proven yet, a few HTC Camera Cab's have been released which increase FPS a miniscule amount, but hardly a fix, and not really enough to say that poor Camera speeds are not because of lack of drivers. I'm not saying they definately are, but from your statement you seem to have completey dis-regarded drivers from the issue.
try messing around with the cache tweaks, or flash a new rom
should i increase or decrease the cache in this situation?
Audio said:
Obviously I'm no Kaiser Wizz, which is why I didn't say "Your problem is because of lack of drivers" (I also missed the sms bit, and thought the issue was only related to MMS, which reading again makes my first post sound insane), but thanks for being patronising in your correcting me and thanks for the mindless sheep insult (which although isn't directly poitned at me, clearly shows I'm the intended recipient).
From what I've seen this has not actually been proven yet, a few HTC Camera Cab's have been released which increase FPS a miniscule amount, but hardly a fix, and not really enough to say that poor Camera speeds are not because of lack of drivers. I'm not saying they definately are, but from your statement you seem to have completey dis-regarded drivers from the issue.
Click to expand...
Click to collapse
You are right, my apologies - I have edited my post.
You will be interested to know that a Mod cannot ban himself - I know I tried yesterday but it tells me I'm an "invalid user" - I knew there was something wrong with me
Mike
heh ^
on a serious and honest note - i beleive that the lack of drivers might potentially have something to do with this, but not the camera
rendering an sms or an mms is mostly a one time render into a buffer of sorts which is then blitted onto the screen - obviously the blitting could/would be hardware accelerated but on a 320x240 screen you arent really going to see a significant slowdown due to moving memory around (as thats all is what happens - in well written software at least) unless the bandwidth is really small - some software however re-renders things based on the changing view rectangle - ie a browsers (internet exploder) view port or the icons in the scrolling programs list (i think this might be compounded by the actual icons not being cached by the OS, so it has to pull them from memory and process them every time) - the lag in these programs are caused by the program re-rendering things many times as the view rectangle changes - this would no doubt vastly improve if/when hw accelerated drivers come out.
to talk numbers 320*240*2 (the 2 is the 16bit colour) is 192k of data for a fullscreen of pixels (excluding any z/stencil/accum buffering etc) now i dont actually know the refresh rate of the device but im guessing its either 30hz or 60hz - so every second, worse case senario, 192k * 60 = 11.25Mb/s of pixel data is flying through the memory onto the screen. actually thats not worst case - because often with (proprietry, non-OS) z ordered windowing/raster systems, things are rendered back to front, sometimes with significant overdraw - pushing the pixel rate up even higher.
if you look at the camera in a nice light bright setting, its smooth and functional - this tells me that the memory has enough bandwidth.
programs that arent coded well (ie they just assume hw acceleration and cosntantly rerender) will feel crap and slow on software renderers - programs that are optimised will have considerably less lag on software but would be super sprightly on hardware. does any of this make sense?
as for the camera - same thing, its just a fullscreen blit of memory - i beleive the problem with the camera is the software that is controlling it and applying that superannoying constant nightmode filter - i can only assume this is being done because of the severely low quality of the camera especially in low light conditions (they must feel the need to 'beef it up' with software post processes).
anyway thats my tangential 2p
same problem here is there any solution so far?
OR again when the speed of the camera was put down to the drivers (and again newer software shows this was not the case).
Click to expand...
Click to collapse
From what I've seen this has not actually been proven yet, a few HTC Camera Cab's have been released which increase FPS a miniscule amount, but hardly a fix, and not really enough to say that poor Camera speeds are not because of lack of drivers.
Click to expand...
Click to collapse
So there is a slight fix for the camera. Can someone direct me to where it can be found?
I've had fairly mediocre success with the camera/camcorder app so far. they're terribly slow to open, the camera app sometimes has a hard time focusing and the camcorder app is continuously refocusing while recording to the point that it looks like the focus drops and then it needs to start over. i've confirmed these issues on my wife's phone, so i know they're not related to just my device.
yesterday, while trying to use the camera app, a black screen appeared with text (almost like a command screen) with "BP Core Dump" or something similar.
the only related thread i've seen where this has occurred was directly related to cyanogen's ROMs, to which i've never used.
640k said:
I've had fairly mediocre success with the camera/camcorder app so far. they're terribly slow to open, the camera app sometimes has a hard time focusing and the camcorder app is continuously refocusing while recording to the point that it looks like the focus drops and then it needs to start over. i've confirmed these issues on my wife's phone, so i know they're not related to just my device.
yesterday, while trying to use the camera app, a black screen appeared with text (almost like a command screen) with "BP Core Dump" or something similar.
the only related thread i've seen where this has occurred was directly related to cyanogen's ROMs, to which i've never used.
Click to expand...
Click to collapse
I've also seen a BP Core Dump, I was using a charger for another phone and it didn't fit snugly. It also said "Trying to activate USB" and eventually rebooted. All this happened on the lockscreen after waking it up.
here's holding out hope for an update soon. love this phone, the hardware is solid. i think moto rushed 2.3.4, though.
640k said:
here's holding out hope for an update soon. love this phone, the hardware is solid. i think moto rushed 2.3.4, though.
Click to expand...
Click to collapse
So after the core dump, I decided to reset my phone and last night, the camera app locked up and rebooted the phone. Today I called tech support and they're sending me a new one. I've read the backorder threads, so it'll be interesting to see when it arrives.
I've looked into this bug a bit more and narrowed it down to /system/bin/mdm_panicd which runs as root. Most likely a bootloader crash.
This is some of the output found in 'strings' for the file , it is what I saw in the "terminal" before it reset.
Code:
BP paniced
Into BP core dump mode
Trying to open USB ...
Also a line "/dev/graphics/fb0" which is what likely created the terminal.
It writes a log to /sdcard/coredump… this may have been on my device which was deleted if I remember correctly.
There was also another thread at droidforums about this. androidforums.com/motorola-droid-3/387878-my-d3-crashed-bp-paniced-error.html
Looking around it looks like there are two bugs for cyanogenmod4milestone opened last year related to this. It was eventually fixed. So this probably can happen on similar Moto devices.
code.google.com/p/cyanogenmod4milestone/issues/detail?id=22
code.google.com/p/cyanogenmod4milestone/issues/detail?id=27
The process has something to do with the modem. Through there's not much info beyond the source code and these trackers. There is a prop in build.prop just after the ril related entries.
persist.mot.mdm_panicd.nopanic=no to allow the dump
I have since had a replacement unrelated to this issue. I've tried a few things mentioned in the above trackers, but cannot reproduce it.
I've attached the strings output for reference, don't know where to go with this but thought I should throw it there.
wow, nice find. all i found was the cyanogenmod stuff
640k said:
wow, nice find. all i found was the cyanogenmod stuff
Click to expand...
Click to collapse
Was hoping for an exploit but very unlikely without it being reproduced.
Can anybody recommend an AOSP-derived ROMs whose developers are enthusiastic about bringing new developers into the fold & have spent some time making documentation and build scripts likely to be relatively straightforward for someone with lots of programming experience (including Android development) and (desktop) Linux experience... but has never managed to actually **build** a ROM from source and make it all the way to a working phone?
Why AOSP (vs Touchwiz) -- there are certain things about Android that have always annoyed me, and I'd love to try and fix. Like implementing "rotate on screen-powerup" (screen orientation normally locked & indifferent to the accelerometer state, but doing an accelerometer read whenever the screen gets turned on by pressing the power button and changing the portrait/landscape orientation at THAT time if appropriate). Or building a hacked browser that prompts to override website directives to not save credentials. Not to mention, fantasies about putting back features that Google took away from us, like ext2-formatted microSD cards. Or jacking up the touchscreen sample rate to the maximum supported by the underlying chipset whenever a Graffiti-like input method is active. Yeah, nothing hard or anything...
The closest I ever came was building CM10 about two years ago for my S3. From what I recall, I managed to get a daily build to compile without errors using a VM somebody made available... but when I finally flashed it to the phone, it just kept rebooting. From what I remember, there were generic instructions for building CM available, but I'm pretty sure there were additional steps specific to the S3 and/or AT&T that were omitted (but mandatory for a working ROM). Or it might have been eMMC-related (I remember that phone was *always* funky about newly-flashed ROMs, and often required multiple flashes before one would "take"). Either way, I ended up badly frustrated & ultimately accomplished nothing.
Hey XDA.
So I'm guessing I'm not the only one wondering if the OnePlus 3 benefits or not from coming with storage encryption by default as per Android Marshmallow OEM requirements. So I put a little experiment together and decided to share my results with the XDA OP3 community.
Disclaimer
None of the results here should be taken as an absolute, as always these tests are flawed and should be taken with a grain of salt, the whole idea of this was to see if disabling encryption would boost "performance" on the device.
Testing Methodology
To attempt to reduce differences that could affect results between both testing scenarios (Encryption enabled and disabled) I followed a set of rules perfoming these tests:
Both scenarios had the phone with the same amount of data that is to say, same apps installed and files on sdcard as to replicate results on an equal and real environemnt (not freshly restored device with no data or apps)
Tests were run back to back for each set of tests. after the first set (Boot Time) there was a 3 minute period for the phone to cool down before perfoming the second set (Antutu) etc.
First all tests were run with encryption enabled after disabling encryption and restoring all apps and data a period of time (5-6min) was taken to ensure device was cool again before tests for the second scenario were started.
Boot Time was done by starting timer as soon as power button was held and holding until OnePlus Logo and Name appeared on screen, timer was stopped as soon as Lockscreen rendered.
Results
Oneplus 3
Encrypted------------------------------------------- Un-Encrypted
Boot Time
0:30:82-------------------------------------------0:30:32
0:34:44-------------------------------------------0:28:98
0:30:78-------------------------------------------0:29:54
0:34:79-------------------------------------------0:28:32
0:34:28-------------------------------------------0:28:15
Median 1,2,3,4,5
M 33:02-------------------------------------------M 29:06 +12%
Boot Time saw a 12% benefit from Unencrypted storage which I expected but in my opinion isn't as big as a difference when compared to other devices with and without encryption before the Snapdragon 820
Antutu
stuck at 70%------------------------------------ 143698
143297------------------------------------------- 143213
141531-------------------------------------------- 142985
141849------------------------------------------- 142895
141501------------------------------------------- 142502
Median 2,3,4,5
M 142045-------------------------------------------M 142899 +0.60%
The first test performed on the encrypted scenario got stuck at 70% and as to not skew results the first scores for both scenarios were ignored when calculating median, here we can see a 0.60% increase in performance for the unencrypted scenario which in my opinion is too small of a difference to draw a correlation between encrypted and unencrypted and worth mentionting is that anyway I believe no significant differences would be tested and found here between both scenarios because of the way encryption works.
Geekbench
2409-----------------------------------------2396
5620-----------------------------------------5597
2433-----------------------------------------2406
5591-----------------------------------------5628
2428------------------------------------------2392
5587----------------------------------------- 5578
2439-----------------------------------------2390
5643-----------------------------------------5581
2431------------------------------------------2391
5569-----------------------------------------5544
Median 1,2,3,4,5
M 2428-----------------------------------------M 2395 -1.35%
M 5602--------------------------------------------M 5586 -0.28%
Here we can observe a decrease in performance of 1.35% in single core results and 0.28% in multi-core results which again in my opinion does not amount to anything noticeable in day to day usage and I believe is not the result of encrypted or unencrypted storage differences
Click to expand...
Click to collapse
Conclusion
Based on these results and this personal experience only, I conclude that for me the only benefit of unencrypting my storage was a shorter boot time (~4sec) and performance wise there is little to no difference at all, and while the security benefits of Android encryption are questionable to say the least. some employers/companies require this to be enabled at all times, and since in these results the differences are so miniscule, there would be at a glance no reason to not stay encrypted if you already are. Although a more in depth testing methodology and cases where storage read/write speeds were predominant would be ideal to maybe see significant differences between performance of encrypted and unencrypted storage, I presume this would not affect a regular user enough to warrant the reformating of all user data if the storage is already encrypted, which will probably be the common state of Android phones that are coming out now and in the future.
Click to expand...
Click to collapse
Obviously this will not replicate the same experience anyone can have so I encourage anyone to reply to this thread with their personal experience on the matter, what is your opinion on encryption? and if you find this post helpful somehow remember to hit the thanks button on my post or any other user that replies helpfully to you. Thanks.
Android's Full-Disk Encryption (FDE) Can Be Cracked on Qualcomm-Based Devices
http://news.softpedia.com/news/andr...racked-on-qualcomm-based-devices-505900.shtml
****
"Although Beniamini is working with both Qualcomm as well as Google, the core of the issue might not be completely fixable and might even require new hardware changes to fix. "
http://thehackernews.com/2016/07/hacking-android-encryption.html
******
I don't know what to think.
Why encrypt when everyone and their mother can crack it?
Seems like our device will never have 'Apple-grade' encryption.
gruntyoldbag said:
Android's Full-Disk Encryption (FDE) Can Be Cracked on Qualcomm-Based Devices
http://news.softpedia.com/news/andr...racked-on-qualcomm-based-devices-505900.shtml
****
I don't know what to think.
Why encrypt when everyone and their mother can crack it?
Seems like our device will never have 'Apple-grade' encryption.
Click to expand...
Click to collapse
"According to Duo Security, 57% of all Android devices, from the company's internal data set, are vulnerable to this attack, the rest having Google's May Android security update installed, which patched CVE-2016-2431, or just don't use a Qualcomm chip."
so if you have the latest OOS which has the June 1st patch, your safe. For now. hackers are always one step ahead, but the chances of your or my device being hacked are slim to none. Look at stagefright, not one single incident.
Nice that they put the script on GitHub tho... And "Apple-grade encryption" means absolutely squat. How do you think iCloud images leak onto the internet?
Read the admentment to my post above.
Also iCloud images leaked because of weak passwords / guessing security questions on the web.
Certainly not because of a weak OS/Chipset.
gruntyoldbag said:
Read the admentment to my post above.
Also iCloud images leaked because of weak passwords / guessing security questions on the web.
Certainly not because of a weak OS/Chipset.
Click to expand...
Click to collapse
I believe that all systems are vulnerable to attackers at some level, even the ones considered the "most" secure (paypal, banks etc.) can and have been hacked.
Apple devices are no more or no less secure than android, (5.0+) both systems have their weaknesses and can be brute force attacked. A lot of security experts are suggesting the Nexus devices to be used if security is a concern as they at least get monthly updates. Nice thing about that is AOSP gets updated around the same time, so custom roms that are kept up to date with the latest merges reap the same benefits as a Nexus device.
FYI: I'm not trying to sound preachy/rude/short or anything, I had a heated argument this morning with my companies IT department as they still want us to use iPhone 5S/BBZ10's instead of new Nexus/Samsung devices.. (our plan is up for renewal)
Well if I understand correctly it requires bruteforcing the password/pin.... I suggest to encrypt but also use a strong password. There's no 100% safe security anyway. It depends of your 'adversary' too. For most users it's not the NSA. So even if the protection is not perfect a strong password should be good enough. You can use the fingerprint reader too (and switch off the phone in some situations, like crossing borders...).
It's a bit concerning that some responding to this OP are basically making light of the very, very serious vulnerabilities mentioned in the above links. Obviously Apple, at least as of the writing of the above articles, seems to have better system for FDE. Especially on their newer chipsets. I really hope that Qualcomm and Google figure out some sort of work around for this for our 820, but also the other QC SoCs that are currently supported.
No, my adversary is not the NSA or other intel agencies(hopefully). I would like a (highly?) reliable method of disk encryption that actually works and isn't compromised in detail on a blog post along with a whole bunch of scripts and code and the developer of hashcat posting in the comments section with goal of collaborating on way to further optimize the attack and integrate into the HC code base.
Call me paranoid but I'll never be any company's, corporation's, organization's or developer's fanboy... IMO I AM THE PAYING CUSTOMER. DELIVER OR **** OFF.
I love Android and OOS is a very true interpretation but as far as security goes this NEEDS to be fixed ASAP in one way or another. Too bad we can't get a copperOS ROM. Even if we had that for the OP3 it appears that the issues are largely the result of QC's implementation of the "TrustedZone".
How to disable encryption?
what would be more interesting are actual i/o speeds before and after encryption not crappy antutu and geekbench, im not gonna get horny of benchmarks from antutu like alot of people do, but read and write speeds are different, i might get a semi
how can i remove this Encryption from recovery????
It does not sound negligibile at all. Why didnt you test with large app starts and app installation. I, for instance, accidentally encrypted my op3t and i noticed by seeing that a game was being installed for an unusually long time.
Thanks. I'm not going to bother with trying to stay unencrypted from now on after seeing this. I always seem to mess the process up and end up encrypted, lol. Like my current ROM. I know the other day I looked and was not encrypted. Now I am. I have no idea what I did but I certainly didn't do it on purpose. I don't care about boot or install times since I don't do that much anyway.
Guys go for unencrypted gives best performance + f2fs for data and cahe both.
I am interested in a buying a 2nd all-arounder phone that mostly ticks all key boxes and found out that the XZ2 is almost there.
As it will be my first Sony I need your experience with the device to decide to buying it or get a different one:
1) are there any serious issues that affect the device, maybe design issues or bad experiences with the device? Maybe display, speakers, or other hardware stuff to concern me?
2) I am interested in root-ability o this phone. Is I saw that there is some development. for this phone and since I am sort of experienced in Custom ROM stuff, I want to know if there are specific rooting issues? Are the valid options for un-bricking it, just in case. Is there a big amount of bricked phones?
3) how's sony with the updates for this device for official firmware updates?
4) is Google Camera functional after rooting?
5) is the phone performance still holding good in late 2019?
I appreciate your responses in any form or shape!
catalindobre said:
I am interested in a buying a 2nd all-arounder phone that mostly ticks all key boxes and found out that the XZ2 is almost there.
As it will be my first Sony I need your experience with the device to decide to buying it or get a different one:
1) are there any serious issues that affect the device, maybe design issues or bad experiences with the device? Maybe display, speakers, or other hardware stuff to concern me?
2) I am interested in root-ability o this phone. Is I saw that there is some development. for this phone and since I am sort of experienced in Custom ROM stuff, I want to know if there are specific rooting issues? Are the valid options for un-bricking it, just in case. Is there a big amount of bricked phones?
3) how's sony with the updates for this device for official firmware updates?
4) is Google Camera functional after rooting?
5) is the phone performance still holding good in late 2019?
I appreciate your responses in any form or shape!
Click to expand...
Click to collapse
I like my still fast XZ2 with OmniROM 9.0
catalindobre said:
I am interested in a buying a 2nd all-arounder phone that mostly ticks all key boxes and found out that the XZ2 is almost there.
As it will be my first Sony I need your experience with the device to decide to buying it or get a different one:
1) are there any serious issues that affect the device, maybe design issues or bad experiences with the device? Maybe display, speakers, or other hardware stuff to concern me?
2) I am interested in root-ability o this phone. Is I saw that there is some development. for this phone and since I am sort of experienced in Custom ROM stuff, I want to know if there are specific rooting issues? Are the valid options for un-bricking it, just in case. Is there a big amount of bricked phones?
3) how's sony with the updates for this device for official firmware updates?
4) is Google Camera functional after rooting?
5) is the phone performance still holding good in late 2019?
I appreciate your responses in any form or shape!
Click to expand...
Click to collapse
1-some devices are affected from bad production including mine, ghosting on LCD below room temperature, horizontal static electric lines appearing after rubbing the screen, speakers may get temporary damage for no reason (can be fixed by opening the sim tray and pulling that paper in there and waiting a little) or can get permanently damaged if you overdrive them with something like xLoud easily, if you dont want a super slippery 200g heavy 1.1cm thick glass brick look somewhere else (buttons are jiggly too)
2-custom roms have problems with audio and camera and it'll take some time to get fixed and at the end there's the possibility of it not being better than stock camera (also typical sony drm stuff will be lost after unlocking the bootloader)
3-device getting regular security patches and will be updated to android 10 in early 2020 (keep your bootloader locked if you want OTA)
4-no, gcam requires full camera2api and raw support which isnt there on stock
5-performance is good probably due to having close to stock android
this is my first xperia and I'd not recommend this phone to anybody unless you are crazy about what is sony doing with their sony open devices project like the guy above martin
Faruk.ErdaL said:
1-some devices are affected from bad production including mine, ghosting on LCD below room temperature, horizontal static electric lines appearing after rubbing the screen, speakers may get temporary damage for no reason (can be fixed by opening the sim tray and pulling that paper in there and waiting a little) or can get permanently damaged if you overdrive them with something like xLoud easily, if you dont want a super slippery 200g heavy 1.1cm thick glass brick look somewhere else (buttons are jiggly too)
2-custom roms have problems with audio and camera and it'll take some time to get fixed and at the end there's the possibility of it not being better than stock camera (also typical sony drm stuff will be lost after unlocking the bootloader)
3-device getting regular security patches and will be updated to android 10 in early 2020 (keep your bootloader locked if you want OTA)
4-no, gcam requires full camera2api and raw support which isnt there on stock
5-performance is good probably due to having close to stock android
this is my first xperia and I'd not recommend this phone to anybody unless you are crazy about what is sony doing with their sony open devices project like the guy above martin
Click to expand...
Click to collapse
I'm sorry to hear that you got a faulty unit.
Did you try to RMA it?
Because I never had such issues, except touch issues in Android 8, which got 90% fixed now (Sometimes while I super fast do swipes on the keyboard it may not recognize only a single swipe at the beginning of the writing).
Camera and Audio are work in progress on the custom roms based on sony open devices project.
SODP is an isolated sony employee team in the sony company + volunteers which need to implement everything by themselves without access to the stock source code (but with access to the closed source Qualcomm source code and documentations).
The camera doesn't degrade on unlock on your stock firmware, so you can freely continue using the stock firmware until the SODP camera reaches a equal or better quality.
(Since SODP supports the entire Camera2API with RAW and GCAM support to raise the quality it may become better than stock.)
And the performance is like stock on SODP.
My benchmark shows the same values like stock, too and you don't have bloat/stock apps preinstalled without the possibility to remove them without root.
PS: The SODP based custom roms are not affected by DRM, since they are a reimplementation of the hardware drivers, there isn't any usecase for DRM keys.