Samsung Galaxy S5
Checkout Details

The checkout page is a summary list where long discussions will not fit. This page is for additional information about the various checkout steps.

Display in Sunlight

The display is excellent in a wide range of lighting conditions. It is hard to fight the sun and win, but in direct sunlight I judge the contest to be a draw. In all light levels the display brightness was adjusted appropriately.

• Outdoor direct sunlight perpendicular to the screen, 140000 lux, under high cirrus clouds. Display is adequate, but not excellent; noticeably less contrast and brightness (compared to the illumination) than in the 4900 lux condition, but color rendition is complete and accurate, and the display in direct sunlight is completely useable, not discouraging or annoying as on older phones. Tested apps: browser showing a formal color test pattern; Google Maps; GPS Status (with a black background, was quite black); ES Note Editor.

  Running the display at maximum brightness has got to eat battery, but I didn't test this quantitatively.

• Outdoor shade, north side of a building, lit by open sky with high cirrus, 4900 lux: Display is excellent, complete and normal color rendition, normal contrast. I can't tell if the color balance is dynamically adjusted for the blue sky versus Sol's yellow light -- I doubt it -- but the colors in the test pattern looked normal.

• Indoor, sunny south side of building, 305 lux: Excellent color and contrast.

• Indoor, north side of building, 26 lux: Excellent color and contrast.

• Dark closet, 0 lux (probably more like 2 lux, from the screen): Excellent color and contrast.

Display in Artificial Light

The Galaxy S5's AMOLED display, viewed in artificial light, gives good color rendition which is independent of the viewing direction. When viewed at a radical angle, e.g. nearly edge-on, the brightness is maybe about half that for perpendicular viewing.

Light valve (LCD) displays generally have trouble giving good color when viewed off perpendicular. The IPS (In Plane Switching) technology is currently best in this aspect.

Ambient Light Sensor

The ambient light sensor works, and influences the display brightness. It is on by default in both the stock image and CM-10, but you can turn it off, and at least on CM-10 you can tweak the control parameters. It's in Settings - Device - Display&Lights - Adaptive Brightness (turn on). Under Live Display you can set it to tweak the colors for day and night (as defined by the clock), and you can adjust the tweakage.

About lux: The light flux is reported in lux, from 140000 lux in (today's) direct sunlight to 1 lux in a dark closet. The value can be seen on Phone Tester and on GPS Status :-) See this Wikipedia article about luminous efficiency. Lux means lumens per square meter and lumens are proportional to watts but depending on how strongly the eye responds to the various colors in the light. The denominator may be the total power into the lamp or the equivalent power of the emitted light. On the latter definition, the theoretical maximum scale factor is 683 lumen/watt. Going by power input to the lamp, practical lamps range from 0.3 (candles) to 100 lumen/watt for the highest scoring LED lamps and plasma (fluorescent) tubes, which are similar in efficiency.

Details About the Internal SD Card

There is 16Gb of internal NOR flash memory, where the HTC Dream had 256Mb of NAND flash. /proc/mounts show these partitions mounted; there are definitely partitions we don't see for the booter, the kernel, and probably the radio image. Sizes here are in Gb (2³⁰ bytes). These are for CyanogenMod-12.

It would appear that the internal SD card is only mounted through FUSE. /sdcard is a backward compatibility symlink to one of its various FUSE mountpoints, /storage/emulated/legacy . The original Android-2.x used this mountpoint.

/mnt/media_rw/sdcard1 is the real mountpoint for the external SD card. It is normally accessed through a FUSE mount on /storage/sdcard1, or through the symlinks /extSdCard or /external_sd. These have got to be for backward compatibility with apps written for previous Android versions where these were actual mount points.

Data Speed Tests

The data speed test is to download a compressed (MP3) music file of 1.31e6 bytes (1.25Mb) or 1.05e7 bits, using HTML protocol (no encryption, no second compression). Note, all the data rates in this section are in bits/second, not bytes/second.

Download times for this file:

Via 802.11g at 5.4e7 bits/sec the download should take 0.19 seconds. The theoretical speed is never achieved in the wild, but the Galaxy S5 is clearly not getting the benefit of the higher data rates possible in 802.11n (up to 6e8 bits/sec), likely due to limitations in the access point.

The theoretical maximum rate for HSPA+ is 1.68e8 bit/sec download (and 2.2e7 bit/sec upload, not tested), never achieved in the wild. The lowest fallback download speed is 2.1e7 bit/sec. The theoretical speed on LTE is 3.0e8 bit/sec with a fallback to 1.0e8 bit/sec. These assume client equipment (multiple antennas) that we don't have, no competing traffic of any kind, and strong signals with no noise sources. This Wikipedia article comparing wireless data standards gives some estimated typical data rates: HSDPA (HSPA download) around 2.0e6 bit/sec; no estimate for LTE.

If Bluetooth (music via A2DP) is running at the same time as the speed test, it slows down 802.11 radically, and cellular data noticeably.

Refer to the speed test section for the Galaxy S3 for its speed and that of earlier devices.

Bluetooth Testing

• How to find the MAC address (in CyanogenMod-10): Settings - System - About Phone - Status - Bluetooth Address. Bluetooth has to be turned on for this to appear. Also, using the terminal emulator you can do: cat /sys/class/bluetooth/hci0/address

• Pairing with other cellphone: Need to test

• Pairing with Xena (Linux laptop): Works. Procedure: Make Selen (cellphone) discoverable. Start the setup wizard on Xena. Xena shows a random number, Selen shows the same number. Click on Pair on both devices (if the number is the same).

• OBEX push: Selen does not have an OBEX server unless you install an app that includes one. Xena also does not have an OBEX server installed. So this did not work in either direction. See also ES File Explorer, which has an OBEX client (sender).

• Pairing with Think Outside keyboard: Works. The HID and the onscreen keyboard keycode (or keysym?) streams are merged so you can use both within the same app (editor) session. Procedure to pair: Open the keyboard. Press Ctrl-Green-Blue until the keyboard's green light blinks (near the T key). Tell Selen to scan for devices. When the keyboard appears, click its line item. Selen pops a box, type a sequence of numbers (4 is known to work, probably more is OK) and hit Pair. Then type the same numbers on the keyboard (use blue Fn key to get numbers) and press enter. It will pair.

• Pairing with 66 BT Sport headphone: Works. Procedure: Hold down the headphone's call control button until you get the turn-on beep and keep holding another 5 secs or so until it gives a double beep at a lower pitch. It is now discoverable. On the cellphone, hit Scan For Devices. The headphone will first appear as just the MAC address, but soon the brand name and device class will be discovered. Click on its line item. It will pair with no further user interaction.

  When you turn off the headphone it is easy to accidentally initiate a call to your most recent voice chat partner (embarrassing). To avoid this, use the settings for the headphone to suppress using HSP/HFP, only A2DP (audio).

• HSP-HFP with 66 BT Sport: Works in CM-12, and HFP (call control button) is obeyed. It will pause music that is playing at the time.

• A2DP audio quality: Adequate. Comparing the same phones (this was evaluated with a Motorola HT820) doing Bluetooth A2DP vs. wired (3.5mm jack), the wired quality is noticeably better. A similar difference is seen on Android-1.5 Cupcake, Android-2.2 Froyo, and Linux bluez-4.88, suggesting that the problem is in the headphone or the A2DP algorithm. It's hard to be sure what the difference is, but I have the impression that the sub-bands in the midrange are not getting matched up perfectly by the headphone.

  There is a new amendment to the A2DP specification: other codecs can be negotiated beyond the sub-band codec, including MP3 and MPEG-4 (audio only of course). It's hard to tell if CM12 or the 66 BT Sport are using these codecs, but the sound quality does seem better than before.

Multimedia Checkout

Outcome of various audio sources and formats (on CM-12); URLs of the nonlocal sources were attempted by the browser, except as noted, and in most cases were handed off to one of the apps. -- indicates that the player either rejected this media type, or offered to download the whole file, which is useless for playing media.

Comments on the player software:

• Firefox Player: It will play Ogg Vorbis streaming media but not MP3. If you hit Back, the player exits.

• Google Music: It is mainly for local media on your phone, all three formats. It will play MP3 streams but not Ogg Vorbis and not M3U. If you hit Back you return to the origin page in the browser but the backend continues playing the music. There's a notification with player controls; it has a green background and a 2x8th note logo.

• ES Media Player: It's a simple player that gets the job done, similar to Google Music but the UI design is more utilitarian, e.g. a gray background rather than green. Comes with ES File Explorer.

• ES Downloader: Its purpose is to download an entire URL, which is not useful for streaming media.

• Apollo: This was my favorite player in CM-11 (KitKat) and earlier, but it is not being developed any more and has become missing.

Results of my standard web browser test:

Details of the Battery Test

Here is a history of draining and charging the 2800mAh battery of the Galaxy S5. For discharging, I used a simple but standard test, doing SHA512 sums of every file in /system/apps (about 250Mb, which will fit in the memory cache). All four cores repeated this continuously. The screen was on, but at normal brightness. Battery temperature was 43C during the test, vs. 27C before the test. With extra work it would have been possible to raise the power demand, e.g. by making the graphics processor perform a video over and over. For charging, I used the 2 amp charger provided with the phone.

So the phone did the test for 2.5 hours. I planned to terminate the test when the battery voltage dropped to 3.20 volts, but it ran a little bit beyond that. A fully charged battery quickly drops from 4.33V to 4.04V at 86% charge, then very gradually declines to 3.50V at 11% charge, and drops precipitously after that.

The phone charged to 82% in 80 minutes (1 hour 20 mins), at which point the voltage reached its safety limit of 4.40V. It then took reduced current for another 40 minutes to reach 100% charge.

Batteries degrade with time and use. Watch this space for future battery statistics. This list gives the time to do the standard test from 100% to 3.20V more or less.

• 2015-05-25: 151 mins

Jimc's Suggestions for Saving Battery Power

• If your cellular signal is poor, more power is needed to talk to the tower, and when the signal drops out it has to scan for another tower. My HTC Dream could only do this for about 6 hours before emptying the battery. Cure: fire the weasels and get a mobile operator that gives you a decent signal. If you're temporarily in a location with poor or no cellular signal (like an airplane), put the device in airplane mode.

• If you are away from your home or work Wi-fi, it has to scan frequently for a Wi-fi provider that it's allowed to connect to. Running the radio frequently and for a long time on each try eats battery. Cure: turn off Wi-fi when you know there's no service. In CyanogenMod, flick down the status bar and you will find a control icon for Wi-fi.

• If you do location-based social networking, it needs to determine your location frequently. Cure: turn off GPS until you need it for map navigation or for finding a specific person. Use your status bar control icon. The position inferred from cell towers should be good enough for many purposes, e.g. picking a restaurant.

• If you are inside a building with steel and concrete construction, which blocks the signal of the satellites, the phone will run the GPS for a long time before giving up, repeating each time your location is needed. Steel and concrete also reduce your cellular signal. Cure: turn off GPS until you are under clear sky. Turn on airplane mode if your cellular signal is uselessly low.

• With a LED (AMOLED) display it takes zero power to show a black pixel, and so you should use a theme with a dark background. But this issue is irrelevant with a light valve (backlighted) or transflective display.

• Turn down the display brightness. If you have an ambient light sensor, use it to automatically reduce the display brightness indoors (and brighten it outdoors).

• Some web pages have active and expensive client-side scripting; for example I ran into one with animated snowflakes that pegged my CPU. Cure: load a more friendly page, and beg Google for a browser setting to suppress client-side scripting.

• Push e-mail eats battery if the server is Dovecot; details are given with the K-9 mail reader app writeup. If you don't use push e-mail (IMAP IDLE) this problem will be avoided.