Rawad Rants About the Size of Charging Cables

In this newest installment of Rawad Rants, Rawad freaks out about the short length of the charging cables that ship with your phone.

For one reason or another, OEMs insist on packaging the smallest cable possible with your new phone. Over the years it seems they have gradually become shorter. We are now at the point where my phone can barely rest on the edge of the table wile charging, and the outlet is right underneath it! Recently I had to order a portable battery pack just so thet I could still use my phone at my desk, while it is charging. In Rawad’s case, he soldered two of his cables together in order to get the length he wanted.

One of the reasons thrown out there for the small cables is that it helps your phone charge quicker. However the difference in charge time between a 1 meter cable and a 3 meter cable is going to be almost non-existent.

Check out the video to see Rawad’s full rant.

Actual USB cable shipped with Nexus 6P

 

from xda-developers http://ift.tt/2bGYmAX
via IFTTT

Honor 8 Camera Tip and Tricks

Jiayu S3 Plus (MediaTek MT6753) Receives Unofficial AOSP 7.0 ROM

Courtesy of Team MAD, the Jiayu S3 Plus with its MediaTek MT6753 SoC) has beaten several Snapdragon devices to receive an unofficial build of AOSP 7.0! Head on over to the forum thread to check it out!

from xda-developers http://ift.tt/2bVBDPH
via IFTTT

Sony Posts Guide on Building AOSP 7.0 Nougat for its Xperia Smartphones

If, for some reason, you were still of the opinion that an OEM could never be developer friendly, Sony has given yet another example of being just that.

On its official website for all developer resources, Sony has posted a build guide for building Android 7.0 Nougat, the AOSP flavor and not its skinned variant, for its Xperia branch of devices. And yes, before you ask, there are mentions of Leo (device codename for Xperia Z3). So Sony is indeed helping the users capable of building Android 7.0 to install and experience the same on their device, even if it did not announce that the Z3 will receive official Android 7.0.

The guide for building AOSP is very straightforward. You’d need a Linux environment to build if you follow the guide, and the guide also lists the tools and environment needed for the build. Once you do have build ready, you’d need a Sony device with an unlocked bootloader to flash the image using fastboot. If all went well, you should have a Sony Xperia device with Android 7.0 Nougat, brought to you courtesy of the efforts at Sony.

So go on ahead, you have something interesting to do for the weekend! Let us know your xperience in the comments below!

from xda-developers http://ift.tt/2boNLqH
via IFTTT

[Winners Announced] Mega-charger Crate Giveaway!

We giving away a whole bunch of these Allmaybe 60W, 6 port charging towers. 10 lucky winners will receive a box full of these awesome chargers. Whether you gift them to your friends or have one in every room in your house, they are yours to do with what you want!

• Power: 60W
• Input: 100-240V~1.45A 50-60Hz
• DC Output: 5V/12A (each port 2.4A max)
• Size: 99(L) x 80(W) x 29(H) mm / 3.9(L) x 3.1(W) x 1.1(H) in
• Weight: 198g/7.0 oz

These chargers do charge devices quickly however don’t support any particular OEM charging platform such as Dash Charging or Quick Charge. They come with a great soft-touch coating and don’t get too hot. If you want to find out more about these awesome chargers, you can check out an awesome review of the chargers here complete with in-depth analysis of current, thermograms and tear down, or you can visit the official product page over at Allmaybe.

To enter the giveaway all you have to do is simply leave a comment below answering the question:

“Which was the best phone for its time and why?”

From the HTC HD2 to the Note 7, if you think a phone stood out from the crowd we want to know. So share your thoughts and then confirm it in the RaffleCopter and we’ll pick the winners at random on the 27th of August. Good Luck!
a Rafflecopter giveaway

from xda-developers http://ift.tt/2b570LJ
via IFTTT

Comparing Battery Life with and Without Google Services: A Week of Minimal Idle Drain

It’s no secret that battery life on smartphones these days are not the best. Most will consider it mostly a hardware issue, seeing companies trading battery size for aesthetic design. But that’s not the entire reason, with a large part being attributed to the software used on our phones.

In the XDA Virtual Office, many of us writers will often find the biggest culprit behind our battery woes are attributed to certain processes running rampant. Namely, Google services.

There are currently many ways to provide longer battery life cycles, methods such as: battery banks, battery cases, processor clocking, etc. A usual solution is to disable apps not being used, or apps that are taking up a lot of system utilities. What I wanted to do was disable all of Google’s apps and services on my device, to see if it might give my battery a shot at living longer. Instead of just using a debloater tool, or the stock settings disabler, I chose to go the extra mile, and install Android without any Google Apps, or any Google services.

Since my daily driver doesn’t have an unlockable bootloader (thanks Verizon), I decided to look into the old phones drawer, and chose one of my favorite devices to use. The Motorola Moto X 2014 was the device I had selected for this experiment. For a period of four days, I used the Moto X with CyanogenMod 13 installed, sans any Gapps packages. For comparison, I factory reset the device after the four days was up, installed the same CM 13 zip, and this time installed the Stock Gapps package from the Open Gapps repository.

---

While using each ROM as a daily driver for four days, I depended on them for many of my usual services. Being that I depend on Google Services on a daily basis, going about this experiment proved rather difficult. Below is a list of the Google Apps I used the most, as well as a list of all the alternatives I used.

Google App	Cortana App	Play Music	CM Music App
Keep/Docs	Omni Notes	Google+/Youtube/Maps	Gello Browser
Drive/Photos	Dropbox	Hangouts	No Alternative Found

There are many alternative app stores and repositories on the internet, from the Amazon App Store, F-Droid, XDA Labs, APK Mirror, and plenty of others. To get my apps for this test, I stuck with two store/repositories that I was familiar with using, XDA Labs and APK Mirror.

Going without Google Services on a Google-based platform is no small feat. There was a noticeable lack of functionality across the operating system from day to day. While some services have a browser interface, a couple will only try and direct you to the Play Store… Or the browser site of the Play Store. With Hangouts being one of those without a mobile interface, I was left unable to communicate with a few colleagues and friends.

Speaking of communication errors, Hangouts wasn’t the only service I had trouble with. I may not be a fan of the app, but Snapchat was a complete no go without Gapps. The app requires Play Services to log in, and unfortunately I was left unable to communicate with my friends on two separate services.

Fortunately, my second communication services for my business colleagues was partially functioning. I was able to send and receive messages on Slack, but notifications would not work, as they relied on Google Cloud Messaging. Quite a few other apps had the same issue, meaning I only ever received notifications for calls, texts, and emails.

Trying to substitute google with Cortana was… just not something I subjectively enjoyed. Microsoft’s searching service is welcome competition and is continuing to get better, but it is not enough to compete with the original search engine. The only useful functionality I found with the Cortana app over the mobile page from Google was the option to have a voice search shortcut on my homescreen, which comes in handy more often.

Having to rely on the browser for services I couldn’t access otherwise was a bit frustrating. Being used to having YouTube Red, leaving the YouTube site would stop the audio. This was causing me to become irritated more and more often. As a big music fan, I like to listen to and discover all types of music on my phone. While CM’s baked in music app works, the lack of a streaming service caused me to have to resort to alternative, older methods of discovering music.

---

Using the phone for about a week both with and without Gapps concluded with interesting results. As you can see from the screen captures below, the average screen on time and total battery time on the No Gapps runs was no longer than that of the Gapps runs. However, do notice the steeper slopes in the (slightly shorter) asleep times.

No Gapps:

With Gapps:

These results are not what I expected going into the experiment. Looking at the battery graphs, you can tell that the runs with Gapps yielded more device wake ups, as expected. This is evident by the Gapps runs not only having more active indication on the bars below the graph. The Gapps graphs all have a much more gradual slope associated with them, whereas the No Gapps graphs seemed to level off a lot more often. But screen-on drain was about the same, with the main difference seen in idle drain as expected.

In terms of performance, there was a negligible difference. Apps certainly crashed more often on the Gapps run, with the main culprit being Hangouts (as usual). Running benchmarks on each run seemed redundant, given I was using the same exact processor and CPU and these processes amount to a negligible hit on the processor .

---

All in all, this experiment was fun. Despite the lack of functionality, it was interesting to challenge myself to work around such large limitations. So that brings us to our main inquiry, is it worth it to live sans Google Apps and Services to save a little on battery? To me, the short answer is no. While the battery life was consistent, it was not particularly longer in any way. It might be useful to live Sans Gapps if you are looking to limit yourself from using your phone on a vacation or something, but not much else. If I had to sum up the lack of functionality, I would say the experience is reminiscent of the feature phone days before the smartphone boom.

Hello my old friend

What do you think of my results? Is there any odd software test you want me to try? Let me know in the comments below.

from xda-developers http://ift.tt/2bsWeJo
via IFTTT

Opera’s Security Breach Highlights a Problem with Proprietary Password Managers

Last night, Opera Software reported a security breach affecting all users of their web browser’s built in password manager. 1.7 million users had both their synchronized passwords and their authentication passwords leaked.

Opera, to their credit, appears to be acting relatively swiftly to notify their users, sending out emails to users of its sync service and posting on their security blog about it within a week of detecting the issue, but therein lies the problem. While they may have detected the attack this week, we have no way of knowing when the attack originated, or even the true extent of the attack, and neither do they. LinkedIn was hacked in 2012, and didn’t discover the full extent of it until 2016 when someone posted an extra 117 million emails and unsalted passwords online. You can only positively identify that specific files were accessed; you can’t guarantee that other files weren’t accessed. You can’t prove a negative.

If you want security, you need to act under the assumption that any and all files can be and have been accessed. You need to design your system around the idea of Defense in Depth. At an enterprise level, it’s not good enough to just have system monitoring software to detect when the intrusion happens. You need logs to discover what was accessed. You need encryption (and good encryption at that) and properly hashed and salted passwords to make it harder for the data that has been taken to be read. You need firewalls, and virus scanners, and regular security audits, and you always need more. There’s no such thing as too much security; the only real limits are cost and time.

So how do you decrease the amount of time and money that you spend to implement your security solution? How do you improve your security solution without going over budget?

By using proven solutions that have been extensively tried, tested, and improved. “Given enough eyeballs, all bugs are shallow“, and the place with the most eyeballs is the open source world. It doesn’t matter how smart you think you are; you are not going to create a better encryption or hashing system than the ones that teams of the world’s leading experts on encryption and hashing have worked together to create and improve (and you would have to spend a ridiculous amount of money to even come close). More importantly, even if you somehow do manage to create something almost as good, if you keep it closed source you would soon fall behind, as bugs are found, reported, and fixed for the open source equivalents by both independent developers, and people from the millions of companies that use the software. Some major companies even have entire teams dedicated to looking for (and reporting) bugs in other people’s software to help patch them.

In the Information Security world, there’s a saying: “Security through obscurity is no security at all.” The idea of security though obscurity has been rejected by experts for hundreds of years, and yet many companies still practice it. Even Opera in their attempt to notify their users of the breach is avoiding answering certain questions (some of which they have answered previously) that would help verify the severity of the breach. Opera is claiming that revealing “how authentication passwords on [their] systems are prepared for storage … would only help a potential attacker,” but it couldn’t be further from the truth. Revealing what encryption system is used does not help break it, as long as a secure system is used and it is properly implemented. In fact, one of Opera’s main competitors, Firefox, extensively details their password sync encryption methods specifically for the purpose of helping improve the security of it. Even worse, it appears that more was leaked than Opera was initially letting on, with comments from Opera’s representatives revealing that the browsing histories and bookmarks of users of Opera Sync may have been leaked unencrypted as well.

And therein lies the risk in trusting your passwords to a closed source service. You can’t verify what security measures they are using, you can’t verify that they are being implemented correctly, you can’t verify that they are properly monitoring for intrusions, etc. It creates a situation where you’re hoping that they did everything correctly, and have no recourse if they didn’t (and as with LinkedIn up above, you may not find out that they didn’t until many years down the line). If your password for a site leaks and you use that same password anywhere else, then your accounts on all of those sites are now compromised.

Using a closed source service also runs the risk of a formerly trustworthy company becoming a bad actor. If a company is bought by another company or is in financial distress, you may see substantial changes in their corporate culture. This could potentially lead to the company in question pushing an update to the software which could decrypt the passwords (without the user knowing), and send them in plain text to the company for uses that the user may not be pleased with. In certain circumstances, you may even see a company deploy a modified version of the application to target specific users (as the FBI recently attempted to force Apple to do).

The only software that a security researcher will typically recommend is software that has been routinely audited by multiple trustworthy third parties, and the only way to realistically achieve that is by being open source. Anyone can look at the code, find bugs, and submit patches for them (whereas with closed source software, people can only find bugs, not fix them). Thankfully, there is a fantastic offline password manager. KeePass has routine security audits, and to this date has yet to see an exploit that didn’t require full administrative access to a computer while you are logged into KeePass (which highlights the importance of Defense in Depth and protecting against things like keyloggers).

KeePass solves many of the problems associated with both closed source password managers and with not using password managers. It avoids issues associated with reusing the same password across multiple sites by allowing you to generate pseudorandom passwords unique to every site you use. It reduces the risk of weak passwords by reducing the number you have to remember down to only a couple (or even just one if you’d like). It is managed locally, removing the risk of an update being pushed without your knowledge. It can be synced across devices using whatever service you’d like (Dropbox, Google Drive, OneDrive, MEGA, etc.). It’s not the ‘be all end all’ of security, but it is an important link in the chain, and helps provide some extra peace of mind.

Do you use a password manager? Have you had bad experiences with website hacks? Let us know!

from xda-developers http://ift.tt/2by9myG
via IFTTT