LightBlog

vendredi 25 novembre 2016

Japan Display unveils dense 651ppi display for VR headsets

google-daydream-view-review-6-of-28-1024x578

google-daydream-view-review-6-of-28-1024x578

This post was originally published on VRSource.

Japan Display (JDI) has just unveiled its latest LTPS TFT LCD technology specifically designed for virtual reality and head mounted displays. Its new panel aims to solve pixel density and refresh rate problems associated with some VR displays. The 3.42-inch panels boasts a 1440×1700 resolution that results in a rather impressive pixel density of 651 pixels-per-inch, which should help to remove that pesky "screen door" effect that can be noticed with lower density panels.

Currently, the panels used in the biggest commercial VR headsets are stuck below 500 PPI. The HTC Vive, Oculus Rift, and Playstation VR offer pixel densities of 447, 461, and 386 PPI respectively. Samsung's Gear VR headset paired up with a QHD smartphone panel offers a clearer picture with 557 pixels per inch, but JDI's latest display still goes one better. Although it's not as good as the 1008 PPI prototype recently shown off by Sharp.

The image below show an example of the "screen door effect", which manifests as a distracting grid of visible pixels.

jdi-display-ppi-comparison

jdi-display-ppi-comparison

The other half of a good VR display is a high refresh rate, and JDI's 3.46-inch VR panel matches the 90Hz rate found in today's commercial VR headsets. High refresh rates are important to help reduce motion blur and prevent the wearer from feeling motion sickness.

Eagle eyed viewers will have spotted that this is an LCD panel rather than an OLED type seen in today's VR headsets, and yet the display looks to be competitive with OLED in terms of important black-to-white latency too. The recently unveiled Google Daydream specification states that display Black-to-White latency must be less than 3ms, and this panel offers a typical 3ms response, falling to 6ms worst case, which just falls a little short of ideal. This was achieved using a strobing backlight technology, which helps to greatly reduce motion blur on LCD panels.

See also:

Sharp showcases a 1008 PPI prototype display for VR headsets

October 7, 2016

Japan Display also has plans for a 800 PPI version of this panel in the future, which should make for a much more crisp viewing experience, providing there's the GPU power available to push all those pixels. This 3.42-inch display has started sample delivery, but we'll have to wait and see if anyone picks it up for their next VR headset.



from Android Authority http://ift.tt/2gnWaxg
via IFTTT

LG G6 iris scanner and MST mobile payment rumored again

LG G5-25

LG G5-25

Industry experts have popped up with another batch of rumors for next year's LG G6 flagship, again hinting that the phone could come sporting iris scanning and mobile payment technology that is designed to rival Samsung Pay. The theory is that LG needs a blockbuster phone packed full of cutting edge technology to help make up for the 800 billion won ($67 million) loss after the launch of its modular G5 model.

LG Pay has been rumored for a while now, and the latest industry chatterboxes are suggesting that the company has developed its own Magnetic Secure Transmission (MST) technology and has dropped its White Card idea. MST technology, which is current used only by Samsung Pay, supports older magnetic credit card machines in addition to modern NFC payment terminals, and would offer LG an advantage over Apple and Android Pay solutions.

"Unlike strong sales in home appliances and television, LG posted historical losses from its mobile communication unit this year. For a rally in shares, the rebound from G6 is important next year." – Kim Ji-san, analyst at Kiwoom Securities.

About a month ago, LG Innotek announced an all-in-one iris scanning module, but refused to confirm whether or not the module was destined for use in future smartphones. The two-in-one module combines camera and iris scanning technology into a single component, to save on costs and optimize performance. The assumption is that the iris scanning module could be tied in directly with the company's mobile payment system.

See also:

LG announces all-in-one iris scanner, possibly for next year's G6 (Updated with LG comment)

4 weeks ago

The first smartphone on the market with an iris scanner was the Galaxy Note 7, before it was recalled. The technology will likely reappear in Samsung's upcoming Galaxy S8, but this delay does offer an opportunity for LG to catch up and compete with the industry leader.

There aren't many rumors floating around about the LG G6's technical specifications just yet. A next-generation Snapdragon 835 processor and QHD display seems a likely base, and the company is expected to drop its modular concept for the phone, something this report also claims.

What technologies would you like to see packed into the LG G6?



from Android Authority http://ift.tt/2gnPPlg
via IFTTT

Create Location-Aware Android Apps with Google Maps

create-location-aware-android-apps-with-google-maps

create-location-aware-android-apps-with-google-maps

Not too long ago, if you were traveling to a new or unfamiliar place then you had to bring a physical map along with you, or at the very least do some research beforehand and be prepared to ask for directions if you ended up getting lost.

Maps on mobile devices mean that getting lost is rapidly becoming a thing of the past, as not only does your typical smartphone put a map of the entire world at your fingertips, but it can also track and display your current location, so you can always see exactly where you are on that map.

Adding a map to your latest Android app project has the potential to greatly improve the user experience – whether you're creating a Gallery app that lets the user see exactly where each photo was taken;  an exercise app that displays the route you took on your morning run, or a memo app that lets users write themselves reminders that pop up automatically as soon as they reach a specific location.

In this article, I'll show you how to use the Google Maps API to add maps to your Android applications. These maps are based on Google Maps data, and will have the same appearance and much of the same functionality as the maps you encounter in the official Google Maps for Mobile app.

We'll start by using Android Studio's built-in Google Maps template to quickly generate an application that displays a map, before adding localisation awareness so this app is able to track and display the user's current location.

Create your project

The Google Maps Android API is distributed as part of the Google Play Services SDK, so the first thing you should do is launch your SDK Manager and make sure you have the latest version of Google Play Services installed – if an update is available, then now's the time to install it.

Next, create an Android Studio project with the settings of your choice, but when you reach the 'Add an Activity to mobile' screen, make sure you select 'Google Maps Activity.'
select-google-maps-activity

select-google-maps-activity

The benefit of using this template, is that most of the code needed to display a map gets generated automatically – you'll only need to make a few tweaks and you'll have an app that's capable of displaying Google Maps data.

Before we make these changes, let's take a closer look at this automatically-generated code, as it provides a pretty good example of how you should go about adding maps to your Android applications.

Let's start with our project's res/layout/activity_maps.xml file. Open this file and you'll see that the map element is inserted into your layout via a MapFragment.

MapFragment functions much like your typical fragment – it represents a portion of your user interface, and you can combine it with other layouts to create a multi-pane layout. However, in addition to acting as a container for your map, MapFragment automatically handles all of your map's lifecycle needs, making it one of the easiest ways of inserting a map into your application.

Your automatically-generated activity_maps.xml code should look something like this:

  <fragment xmlns:android="http://ift.tt/nIICcg"  xmlns:map="http://ift.tt/GEGVYd"   xmlns:tools="http://ift.tt/LrGmb4"  android:id="@+id/map"    // If Android is going to recognize this fragment as a MapFragment, then you must set the  // fragment's android:name attribute to "com.google.android.gms.maps.MapFragment"//    android:name="com.google.android.gms.maps.SupportMapFragment"  android:layout_width="match_parent"  android:layout_height="match_parent"  tools:context="com.jessicathornsby.myapplication.MapsActivity" />  

Declaring your MapFragment via XML may be the most straightforward solution (and it's the approach I'll be using throughout this tutorial) but if you need to, you can add a MapFragment programmatically, by creating a MapFragment instance and then adding it to the current Activity, using FragmentTransaction.add:

  mMapFragment = MapFragment.newInstance();  FragmentTransaction fragmentTransaction =          getFragmentManager().beginTransaction();  fragmentTransaction.add(R.id.my_container, mMapFragment);  fragmentTransaction.commit();  

The other automatically-generated file that's worth exploring in detail, is your project's MapsActivity.java file:

  import android.support.v4.app.FragmentActivity;  import android.os.Bundle;  import com.google.android.gms.maps.CameraUpdateFactory;  import com.google.android.gms.maps.GoogleMap;  import com.google.android.gms.maps.OnMapReadyCallback;  import com.google.android.gms.maps.SupportMapFragment;  import com.google.android.gms.maps.model.LatLng;  import com.google.android.gms.maps.model.MarkerOptions;    // Since we're adding our map via a fragment, this Activity needs to extend FragmentActivity.  // You'll also notice that your project is implementing onMapReadyCallback, which gets  // triggered when the map is ready to use//     public class MapsActivity extends FragmentActivity implements OnMapReadyCallback {   // GoogleMap is the main class of the Maps API and is responsible for handling important  // operations such as connecting to the Google Maps service, downloading map tiles,  // and responding to user interactions//  private GoogleMap mMap;       @Override     protected void onCreate(Bundle savedInstanceState) {             super.onCreate(savedInstanceState);             setContentView(R.layout.activity_maps);            // Obtain the map from the SupportMapFragment//      SupportMapFragment mapFragment = (SupportMapFragment) getSupportFragmentManager()         // Call FragmentManager.findFragmentById() and pass it the ID of the UI element where      // you want to display your map, in this example that's 'map'//      .findFragmentById(R.id.map);        // You can't instantiate a GoogleMap object directly, but you can use getMapAsync to set a      // callback that's triggered once the GoogleMap instance is ready to use//        mapFragment.getMapAsync(this);         }    @Override  // Set an instance of OnMapReadyCallback on your MapFragment. If the user doesn't have  // Google Play Services installed,then at this point they'll be prompted to install it  public void onMapReady(GoogleMap googleMap) {            mMap = googleMap;            // This sample app cannot access the user's location, but it does emulate this functionality      // by displaying a 'you are here'-style marker that's hard-coded to appear at Sydney,      // Australia. Here, we're defining the latitude and longitude coordinates this marker will      // use      LatLng sydney = new LatLng(-34, 151);        // Add a marker to the map at the 'Sydney' coordinates. Unless you specify otherwise,      // Android uses Google Maps' standard marker icon, but you can customize this icon by      // changing its colour, image or anchor point, if required.      mMap.addMarker(new MarkerOptions().position(sydney).title("Marker in Sydney"));        // Use CameraUpdate to move the map's 'camera' to the user's current location - in this      // example,that's the hard-coded Sydney coordinates. When you're creating your own apps,      // you may want to tweak this line to animate the camera's movements, which typically      // provides a better user experience. To animate the camera, replace GoogleMap.moveCamera      // with GoogleMap.animateCamera//      mMap.moveCamera(CameraUpdateFactory.newLatLng(sydney));         }   }  

As already mentioned, Android Studio does a lot of the hard work for you, but in its current state this project isn't quite capable of displaying Google Maps data. You still need to make a few tweaks to your code and acquire a Google Maps API key – which we're going to cover in the next few sections.

Updating Project Dependencies

The first change you need to make, is declaring Google Maps and Google Location APIs as project dependencies. Open your project's module-level build.gradle file and you'll see that Android Studio has already added the Google Play Services SDK to the dependencies section:

  apply plugin: 'com.android.application'     ...     dependencies {         compile 'com.google.android.gms:play-services:9.8.0'     }  

The problem is that this will compile the entire package of Google Play Services APIs, which can make it more difficult to keep the number of methods in your app under control. Unless you plan on using a long list of features from this package, then it makes more sense to compile the specific parts of the Google Play Services API that you're actually going to use.

For the sake of a more streamlined project, I'm going to remove this general Google Play Services dependency, and specify that my project uses the Google Maps and Location APIs only:

    dependencies {         compile 'com.google.android.gms:play-services-maps:9.8.0'         compile 'com.google.android.gms:play-services-location:9.8.0       }  

Note, however you declare your Google Play Services dependencies, you should update their corresponding version numbers every time you download a new version of the Google Play Services SDK.

Get a Google Maps API key

If your project is going to pull data from the Google Maps servers, then it'll need a Google Maps API key, which you obtain by registering your project with the Google API Console.

Once again, the 'Google Maps Activity' template has done a lot of the hard work for you. This template includes a google_maps_api.xml file that contains a URL you can use to generate a unique Google Maps API key. Although you can log into the Google API Console independently and generate API keys outside of this template, the benefit of using this URL is that most of the information about your project is already entered for you. In the interests of saving time, this is the method I'm going to use to generate my API key:

  • Open your project's res/values/google_maps_api.xml file.
  • Copy the URL inside this file, and paste it into your web browser. This will take you directly to the Google API Console.

open-the-google-maps-api-file

open-the-google-maps-api-file
  • Make sure 'Create a project' is selected from the dropdown menu, then click 'Continue.'
  • Check the terms and conditions, and if you're happy to proceed click 'Agree and continue.'
  • When prompted, click the 'Create API key' button.
  • At this point, you can choose between generating a generic API key that has no restrictions and can run on any platform, or a restricted API that can run on the specified platform only. Restricted APIs tend to be more secure, so unless you have a very good reason not to, you'll typically want to generate a restricted API by clicking 'Restrict key' from the popup that appears.
  • Under the 'Key restrictions' section, make sure 'Android apps' is selected.
  • Click 'Save.'
  • You'll now be taken to the 'Credentials' section of the Google API Console. Find the API key you just created, and copy it.
  • Hop back to Android Studio and paste this key into your google_maps_api.xml file, specifically its <string name="google_maps_key" element.

When you add the API key to your google_maps_api.xml file, Android Studio should automatically copy this key into your project's Manifest. It's a good idea to check that this has actually happened, so open your Manifest and make sure the following section is now displaying your unique API key:

   <meta-data         android:name="com.google.android.geo.API_KEY"         android:value="YOUR_API_KEY"/>  

Updating your Manifest

While you have your project's Manifest open, let's make a few more changes to this file. Firstly, you'll need to specify the version of Google Play Services that you're using, for example:

  <meta-data     android:name="com.google.android.gms.version"     android:value="@integer/google_play_services_version" />  

If you're targeting anything earlier than version 8.3 of the Google Play services SDK, then you'll also need to add the WRITE_EXTERNAL_STORAGE permission:

  <uses-permission         android:name="android.permission.WRITE_EXTERNAL_STORAGE" />  

Note, if you're targeting Google Play Services 8.3 or later, then your app won't need to explicitly request permission to write to external storage.

Next, since the Google Maps Android API uses OpenGL ES version 2 to render its maps, you should make sure your app won't wind up on a device that doesn't support OpenGL ES 2, by declaring android:glEsVersion 2 as a required feature:

  <uses-feature android:glEsVersion="0x00020000" android:required="true" />  

Most apps that include some form of maps functionality also require the following permissions, so save yourself some time and add them to your Manifest now:

  <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />  

This permission allows your app to check the device's network status, which means your app can determine whether it can currently download data from Google Maps.

  <uses-permission android:name="android.permission.INTERNET" />  

This permission gives your app the ability to open network sockets, so it can download data from the Google Maps servers.

Even though this first version of our app won't display the user's current location, we'll be adding this feature shortly, so you should take this opportunity to add one of Android's location-based permission requests to your Manifest:

   <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>  

Gives your app the ability to access the user's approximate location, using the device's Wi-Fi, mobile cell data, or both.

  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>  

Gives your app the ability to determine the user's precise location, using data from all the available location providers, including GPS, WiFi and mobile cell data.

After you've made these changes to your project's Manifest, you're ready to test your app. Either attach a physical Android device to your development machine or launch a compatible AVD, then select 'Run' from the Android Studio toolbar followed by the device you want to use. After a few moments the app should appear onscreen.
basic-google-maps-android-app

basic-google-maps-android-app

While you can interact with this map by dragging onscreen and pinching to zoom in, in its current state this map doesn't detect your location. Since a map that has no idea where you are in the world isn't particularly helpful (especially when compared to other location-aware apps), let's give this project the ability to detect the user's current location.

Accessing the user's location

There's several ways you can add location awareness to your app, but the easiest method is to use the Google Play Services Location API, which is distributed as part of the Google Play Services SDK.

In the following code, I'm still using the same API key and layout resource file, but I've updated my project's MapsActivity.java file to determine the last known location of the user's device, which most of the time will be roughly equviliant to the user's current location:

  package com.jessicathornsby.myapplication;  import android.support.v4.app.ActivityCompat;  import android.os.Build;  import android.os.Bundle;  import com.google.android.gms.common.api.GoogleApiClient;  import android.support.v4.content.ContextCompat;  import android.support.v4.app.FragmentActivity;  import com.google.android.gms.maps.GoogleMap;  import com.google.android.gms.maps.OnMapReadyCallback;  import com.google.android.gms.maps.model.Marker;  import com.google.android.gms.maps.SupportMapFragment;  import android.content.pm.PackageManager;  import android.location.Location;  import com.google.android.gms.location.LocationListener;  import com.google.android.gms.location.LocationRequest;  import com.google.android.gms.location.LocationServices;    // Since it's the easiest way of adding a map to your project, I'm going to stick with using  // a MapFragment//    public class MapsActivity extends FragmentActivity implements OnMapReadyCallback,  GoogleApiClient.ConnectionCallbacks, LocationListener {     private GoogleMap mMap;     GoogleApiClient mGoogleApiClient;     Marker mLocationMarker;     Location mLastLocation;        LocationRequest mLocationRequest;         @Override   protected void onCreate(Bundle savedInstanceState) {          super.onCreate(savedInstanceState);          setContentView(R.layout.activity_maps);             if (Build.VERSION.SDK_INT & gt; = Build.VERSION_CODES.M) {               checkLocationPermission();          }              SupportMapFragment mapFragment =             (SupportMapFragment) getSupportFragmentManager(.findFragmentById(R.id.map);          mapFragment.getMapAsync(this);     }        public static final int MY_PERMISSIONS_REQUEST_LOCATION = 1;     public boolean checkLocationPermission() {    // In Android 6.0 and higher you need to request permissions at runtime, and the user has    // the ability to grant or deny each permission. Users can also revoke a previously-granted    // permission at any time, so your app must always check that it has access to each    // permission, before trying to perform actions that require that permission. Here, we're using    // ContextCompat.checkSelfPermission to check whether this app currently has the    // ACCESS_COARSE_LOCATION permission          if (ContextCompat.checkSelfPermission(this,                             android.Manifest.permission.ACCESS_COARSE_LOCATION)     // If your app does have access to COARSE_LOCATION, then this method will return     // PackageManager.PERMISSION_GRANTED//                    != PackageManager.PERMISSION_GRANTED) {       if (ActivityCompat.shouldShowRequestPermissionRationale(this,                     android.Manifest.permission.ACCESS_COARSE_LOCATION)) {      // If your app doesn't have this permission, then you'll need to request it by calling      // the ActivityCompat.requestPermissions method//      requestPermissions(new String[] {        android.Manifest.permission.ACCESS_COARSE_LOCATION       },       MY_PERMISSIONS_REQUEST_LOCATION);        } else {      // Request the permission by launching Android's standard permissions dialog.      // If you want to provide any additional information, such as why your app requires this      // particular permission, then you'll need to add this information before calling      // requestPermission //                   requestPermissions(new String[] {        android.Manifest.permission.ACCESS_COARSE_LOCATION       },       MY_PERMISSIONS_REQUEST_LOCATION);             }             return false;    } else {         return true;        }   }     @Override   protected void onResume() {          super.onResume();   }     @Override   protected void onPause() {          super.onPause();   }     @Override   public void onMapReady(GoogleMap googleMap) {    mMap = googleMap;    // Specify what kind of map you want to display. In this example I'm sticking with the    // classic, "Normal" map            mMap.setMapType(GoogleMap.MAP_TYPE_NORMAL);            if (Build.VERSION.SDK_INT & gt; = Build.VERSION_CODES.M) {         if (ContextCompat.checkSelfPermission(this,                     android.Manifest.permission.ACCESS_COARSE_LOCATION)                     == PackageManager.PERMISSION_GRANTED) {              buildGoogleApiClient();      // Although the user's location will update automatically on a regular basis, you can also      // give your users a way of triggering a location update manually. Here, we're adding a      // 'My Location' button to the upper-right corner of our app; when the user taps this button,      // the camera will update and center on the user's current location//                       mMap.setMyLocationEnabled(true);     }    }        else {         buildGoogleApiClient();             mMap.setMyLocationEnabled(true);        }   }   protected synchronized void buildGoogleApiClient() {    // Use the GoogleApiClient.Builder class to create an instance of the    // Google Play Services API client//          mGoogleApiClient = new GoogleApiClient.Builder(this)                .addConnectionCallbacks(this)                .addApi(LocationServices.API)                .build();      // Connect to Google Play Services, by calling the connect() method//            mGoogleApiClient.connect();     }     @Override   // If the connect request is completed successfully, the onConnected(Bundle) method   // will be invoked and any queued items will be executed//   public void onConnected(Bundle bundle) {    mLocationRequest = new LocationRequest();        mLocationRequest.setInterval(2000);        if (ContextCompat.checkSelfPermission(this,                 android.Manifest.permission.ACCESS_COARSE_LOCATION)                == PackageManager.PERMISSION_GRANTED) {       // Retrieve the user's last known location//         LocationServices.FusedLocationApi.requestLocationUpdates(mGoogleApiClient,                                                       mLocationRequest, this);         }   }     @Override   public void onConnectionSuspended(int i) {   }     // Displaying multiple 'current location' markers is only going to confuse your users!   // To make sure there's only ever one marker onscreen at a time, I'm using   // mLocationMarker.remove to clear all markers whenever the user's location changes.     @Override   public void onLocationChanged(Location location) {    mLastLocation = location;    if (mLocationMarker != null) {     mLocationMarker.remove();    }      // To help preserve the device's battery life, you'll typically want to use    // removeLocationUpdates to suspend location updates when your app is no longer    // visible onscreen//    if (mGoogleApiClient != null) {     LocationServices.FusedLocationApi.removeLocationUpdates(mGoogleApiClient, this);    }   }     // Once the user has granted or denied your permission request, the Activity's   // onRequestPermissionsResult method will be called, and the system will pass   // the results of the 'grant permission' dialog, as an int//     @Override   public void onRequestPermissionsResult(int requestCode,    String permissions[], int[] grantResults) {    switch (requestCode) {     case MY_PERMISSIONS_REQUEST_LOCATION:      {         // If the request is cancelled, the result array will be empty (0)//        if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) {          // If the user has granted your permission request, then your app can now perform all its        // location-related tasks, including displaying the user's location on the map//        if (ContextCompat.checkSelfPermission(this,          android.Manifest.permission.ACCESS_COARSE_LOCATION)                        == PackageManager.PERMISSION_GRANTED) {         if (mGoogleApiClient == null) {          buildGoogleApiClient();         }         mMap.setMyLocationEnabled(true);        }       } else {        // If the user has denied your permission request, then at this point you may want to        // disable any functionality that depends on this permission//       }       return;      }    }   }  }  

Now it's time to test your app by installing it on your Android device or a compatible AVD. Launch your app, and it should request access to your device's location.
google-maps-android-permission-request

google-maps-android-permission-request

Grant this permission request and you should see the map – but this time it'll be centered over your current location, complete with an accurate location marker.

Other map types

In this example, we set the map type to "normal," however if you don't like the look of the map that appears on your Android device, then you can always change it to any of the other maps supported by the Google Maps API:

  • MAP_TYPE_HYBRID. A satellite map with a transparent layer displaying major roads and feature labels.

hybrid-google-map

hybrid-google-map
  • MAP_TYPE_SATELLITE. A satellite map with roads, but no labels.

satellite-google-map

satellite-google-map
  • MAP_TYPE_TERRAIN. A topographic map that includes contour lines, labels and perspective shading. Some roads and labels may also be visible.

terrain-google-map

terrain-google-map

Summary

In this article, we looked at how to use the Google Maps API to add map content to your application, and how to display the user's current location on this map, using the new permissions model introduced in Android 6.0. If you'd like to try this project for yourself, you'll find the full code over at GitHub.



from Android Authority http://ift.tt/2gnFfeq
via IFTTT

BLU Vivo 6 Hands On and First Impressions

p1000416

p1000416

The BLU Vivo 6 is a new phone that offers some fairly impressive features at a very compelling price point. An affordably priced device, it nevertheless comes with a 97% metal body, 4GB RAM, 64GB internal storage and a few other surprisingly high-end features. Like any affordable device however, it also presents a number of compromises which are apparent straight away.

p1000385

p1000385

From the front, this is a rather stock-looking smartphone that seems to take design cues from other smartphone. It's entirely white with a single home button with a dot on either side to indicate the capacitive buttons. The back is a bit more exciting though thanks to a rose gold, matte finish that I actually really like. It manages to look fairly premium and eye-catching without essentially being an oblong mirror for a change. This also bodes well for fingerprints. BLU saw fit to include a soft, transparent case for the back too which is a nice touch.

20161123_22020620161123_220206

The display is a 5.5-inch IPS panel of 1080p resolution and while it's not QHD resolution, it is very bright and you'll need to inspect closely to see that this isn't QHD. Corning Gorilla Glass 3 provides some welcome protection and there's also an included screen protector in the package. There's a strange raised piece of glass – which is almost imperceptible – around the entire front of the device that I kept trying to peel off at first; this might be the 'curved display' that BLU keeps talking about but I'm not sure I get the appeal.

p1000410p1000410

There aren't many surprises in terms of the hardware either. The home button features a fingerprint scanner that works in any direction and seems to work well enough from our initial tests. There are also two SIM card slots making the Vivo 6 one of the few handsets to natively offer dual SIM functionality in the UK. USB-C is a forward-thinking choice and while I haven't had a chance to test it, the 3,130mAh battery is promising. For the times when you're running low, Quick Charge helps get you topped up, with the Vivo 6 slated to offer a 40% charge in around 30 minutes.

p1000405p1000405

On the rear, the Vivo 6 has a 13MP Sony IMX sensor coupled with f/2.0 aperture, HDR (in software, not on the lens), Phase Detection autofocus and laser focus. Video recording tops out at 1080p at 30 frames per second while the front facing camera is capable of taking 8MP selfies.

In my quick tests, the camera seems to perform pretty averagely, with a lack of detail and lack of vibrancy prevalent throughout these quick snaps. Of course, we'll be testing this further for the full review.

Under the hood, the BLU Vivo 6 is powered by an octa-core MediaTek Helio P10 processor clocked at 1.8GHz and this is paired with 4GB of RAM and 64GB internal storage, that can be expanded by a further 64GB using the microSD card slot. It's not the best processing package on a smartphone but, considering the price tag, it's more than capable of getting the job done.

20161123_21595220161123_215952

The Vivo 6 is running Android 6.0.0 Marshmallow with a few tweaks from BLU. It's a fairly light skin but with some weird choices. Like many custom Android implementations, there's no app drawer (though this is easily fixed) and for some reason Opera appears to be the default browser. There isn't much bloatware, but most apps that come preinstalled, such as McAfee Security, can be easily removed.

p1000412p1000412

The BLU Vivo 6 certainly won't set the world alight but it is one of the few handsets at this price to offer a solid set of internals. While the design may seem unimaginative, the rear panel is quite nice and overall, it's a functional design that gets the job done. It won't replace your flagship but if you're in the market for a device that offers a solid experience – say, for your tech-shy uncle perhaps – the Vivo 6 certainly seems to tick that box.

Of course, we'll be bringing you a full review in the coming days so stay tuned but for now, let us know what you think of the BLU Vivo 6 in the comments below! If you're interested in buying the Vivo 6, it's available now at a cost of £239, however as a Black Friday launch special, it's reduced to just £184.99! You can pick it up from the link below.

 



from Android Authority http://ift.tt/2goCzk9
via IFTTT

Hugo Barra: “Xiaomi could sell 10 billion smartphones and not make a profit”

xiaomi-mi-mix-review-aa-21-of-27

xiaomi-mi-mix-review-aa-21-of-27

Xiaomi's plummeting smartphone sales are of little concern to the company's bottom line because, according to Xiaomi global vp Hugo Barra: "We could sell 10 billion smartphones and we wouldn't make a single dime in profits. Basically we're giving them to you without making any money… we care about the recurring revenue streams over many years".

There's not many smartphone makers that couldn't care less about declining smartphone sales, but Xiaomi makes its money from connected home devices and its software ecosystem. Smartphone sales are, of course, important to the company, but they are not a financial imperative as with most companies.

See also:

Xiaomi Mi MIX Review

1 week ago

Despite recent poor performance in the smartphone division, Xiaomi's vp Liu De said in April that the company expected sales of smart home devices to double to 10 billion yuan (~$1.5 billion) this year.

With multiple new phones rumored to launch in the very near future, including a possible device targeted at the U.S. market to be announced at CES 2017, Xiaomi's phone sales may well recover from their current slump. As we reported recently though, Xiaomi's foray into India has produced a lot of fans, but alienated a lot of folks at the same time.

Would you buy a U.S. Xiaomi phone? What about other Xiaomi products?



from Android Authority http://ift.tt/2fvn0CY
via IFTTT

OxygenOS 3.2.8 update is rolling out to the OnePlus 3 now

oneplus 3 gold aa (4 of 22)

oneplus 3 gold aa (4 of 22)

OnePlus has released a software update for the OnePlus 3. Before you get too excited, let me just start by saying that this is not the promised Nougat update you are all waiting for. According to the company, Google's latest version of its OS will hit the recently announced OnePlus 3T and its slightly older discontinued brother by the end of the year.

For now, the OnePlus 3 has been updated to OxygenOS version 3.2.8, which brings a few incremental features to the device. The most interesting one is the addition of 1080p 60fps video recording, hinted at recently by the team in a Reddit AMA.

The update also adds an emergency calling feature for Indian users, which can be triggered by pressing the power button three times, as well as Snapchat optimization — with fixes for video calling and scrolling lags. And as always, general bug fixes that should hopefully make the device run even smoother are included in the latest version of OxygenOS.

See also:

The OnePlus 3 will get every update the OnePlus 3T does

3 days ago

If you own a OnePlus 3, keep in mind that the update won't hit all devices at once. A small percentage of users should receive it today, while the rest will be able to download it over the course of the next few days.

Let us know when you receive the update and what you think of it in the comment section below. We always love to hear your thoughts on these things.



from Android Authority http://ift.tt/2fZ5ta0
via IFTTT

Samsung trademarks a male and female voice assistant called Bixby and Kestra

voices-of-life-2

voices-of-life-2

The rumored Samsung Galaxy S8 voice assistant already had a name: Bixby. But now it has a feminine alter ego by the name of Kestra (another Star Trek reference – Kestra was Deanna Troi's older sister). New trademark documents reveal identical applications other than the name, revealing that Samsung is an equal opportunity AI employer.

Trademark filings don't always pan out to anything in the real world, with many OEM's "camping" on terms they may or may not ever take to market. But considering all we've heard about the Galaxy S8's AI virtual assistant, there's no reason to doubt we won't have a male and female voice option when the Galaxy S8 arrives around MWC 2017.

samsung-bixby-kestra-trademark-applications

samsung-bixby-kestra-trademark-applications

The trademark applications, filed in both South Korea and Europe, relate to "interactive computer software," "speech recognition software" and, most tellingly: "computer software for enabling hands-free use of a mobile phone through voice recognition". Hit the source link if you want to peruse the documents for yourself.

Samsung has also applied to trademark multiple spelling variations for Bixby, including Bix-bee, Bix-by, Bix:)bee and Bix:)by. Meanwhile, SamMobile claims to have information related to Bixby Pay, a voice-based payment system that will also arrive with the Galaxy S8. Stay tuned for more Galaxy S8 rumors as we close out the year and get closer to go time.

Would you use a voice-based payment system?



from Android Authority http://ift.tt/2fLShT1
via IFTTT