LightBlog

lundi 3 octobre 2016

Xiaomi Brings the Redmi 3S+ to India via Retail Stores

Xiaomi has been very impressive in their push to increase their online presence. For a long time, buying a smartphone online from Xiaomi was the only official way you could get one of their smartphones or tablets. There have always been unofficial resellers here and there, but the company's flash sales were the only official channel they had and they did this to keep inventory costs down as low as possible.

Then, we started to see Xiaomi branch out a little and sell their products in their own Mi.com webstore as well as 3rd-party websites like Flipkart and Amazon. It had become clear that while the flash sale method works when a device is first released, they could sell much more by expanding their online presence. Online retailers like Flipkart and Amazon have done well for the Chinese electronics maker, but now they're looking for even more retail outlets.

The company just announced they will be building 1,000 of their own brick and mortar retail locations by 2020, but they're also looking to tap into other physical retail stores. It looks like the Redmi 3S+ will be Xiaomi's first smartphone to hit physical retail stores in India. The device was first released back in June of this year and offers reasonable hardware specs for the price Xiaomi sells it for.

You can buy the Redmi 3S+ in India, but it will be available exclusively through the company's retail partners. Xiaomi is advertising a number of their partners in the announcement tweet, but doesn't include them all. So, if you're a frequent Sangeetha, Poorvika, Big C, StoreKing, or Just Buy Live shopper, then you will start to see the Redmi 3S+ on their store shelves. The twitter announcement also mentions it will be available at "other leading retail stores," but doesn't announce the names of those other retail stores.

Source: @RedmiIndia



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

New Pixel and Pixel XL Pictures & Details Emerge as Preorder Pages go Live

There's been a number of Google Pixel and Pixel XL leaks over the weekend and most seem to reassure us of things we've already heard in rumors. And throughout these leaks, we've learned a couple of new things that hadn't been talked about before. There have been official renders leaked from multiple retailers who accidentally pressed the publish button too early. Which is interesting to have seen happen when even Google isn't scheduled to announce them until tomorrow.

First, we learned that Google Pixel and Pixel XL customers will be able to store unlimited "full resolution" images in Photos instead of being limited by the amount of storage you have on your Google account. We also see there will be a "Smart Storage" feature that will automatically free up storage on your phone so you're never told about being out of storage because of the photos and videos you have on your device.

pixelxl2 pixel1

Live Cases will be available for both the Pixel and the Pixel XL so users can use images from Google Earth and Google Trends to personalize their devices. But what will likely excite even more people is the new leak that suggests the Pixel and Pixel XL will be available in 32GB and 128GB variants. This leak comes from a photo that was allegedly taken from the Telstra system. This photo also shows the 2 color options that will be available at launch (Quite Black and Very Silver). There's no mention of the rumored Really Blue in the Telstra system though.

Nexus fans have been begging for Google to sell 128GB variants of their devices for years but the Mountain View search giant hasn't offered them barring the Nexus 6P. It's interesting to see that a 64GB version isn't shown in this leak, and it makes us curious how much the 128GB version will cost since the base model of the Google Pixel is rumored to be priced at $650 here in the United States. In any case, we'll likely learn tomorrow!

Source: Ausdroid



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

dimanche 2 octobre 2016

“Working As Intended” – An Exploration into Android’s Accessibility Lag

The beauty of Android lies in the many different ways that third-party applications can interact with the system. Password manager apps such as LastPass provide the ability to automatically feed relevant username/password data to almost any login screen. Text Aide allows you to significantly shorten your time texting your friends by allowing you to create text expansion macros. Native Clipboard decreases the hassle involved with frequently switching between apps to copy large amounts of text by allowing you to double-tap any input field to bring up a clipboard. Who can forget Greenify, perhaps the #1 most recommended app by enthusiasts, which keeps rogue background apps in check and can thus enhances battery life? Finally, albeit less familiar with most users, there's AutoInput – a Tasker plug-in designed to automate screen taps, text input, swipe gestures, and much more. These apps all serve vastly different use cases, but each of these apps rely on a very misunderstood part of core Android functionality: Accessibility.

To the average Android user, it might seem odd that many of these amazing features utilized by your favorite app are controlled by a setting under the accessibility submenu. Making an app accessible is typically supposed to mean that an Android app is usable to a person with disabilities. So why in the world do LastPass, Native Clipboard, Text Aide, Greenify, or AutoInput have an accessibility service? Furthermore, why does enabling an accessibility service seem to cause so much UI lag? It doesn't seem to matter what version of Android you're on – whether it be Android 5.0 Lollipop or Android 7.0 Nougat – because the lag caused by certain accessibility services can affect your experience. A simple solution to this problem is to merely disable accessibility services you might have enabled – but in doing so, we lose so much useful functionality. Another solution is to petition Google to "fix" Android's accessibility lag, but Google claims that Android Accessibility is working as intended. We've spoken to a few developers intimately familiar with accessibility services and have researched how the functionality works, and we're here to test that claim: is Android's accessibility lag a bug or is it a feature?


Understanding Android Accessibility

As you might imagine by the name, Accessibility is mostly intended for developers to provide additional functionality for any users with disabilities. Indeed, a quick peek over on the official documentation pages for Accessibility reveals that Google has a pretty narrow view on what kinds of services should be provided by Accessibility Services.

Many Android users have different abilities that require them to interact with their Android devices in different ways. These include users who have visual, physical or age-related limitations that prevent them from fully seeing or using a touchscreen, and users with hearing loss who may not be able to perceive audible information and alerts.

Android provides accessibility features and services for helping these users navigate their devices more easily, including text-to-speech, haptic feedback, gesture navigation, trackball and directional-pad navigation.

Google's TalkBack, which comes pre-installed on every Android phone, is a great example of what the 'typical' Accessibility Service is supposed to be like. Voice Access takes accessibility a step further and allows for almost complete control of your phone using only your voice. But the fact that Google intended Accessibility Services to be used in this manner does not prevent developers from implementing them in whatever way they want – and that's exactly what developers have done. It's exactly because of the way that Accessibility works that makes the feature incredibly useful to users with or without disabilities.

Voice Access on Android - UI Navigation Voice Access on Android - Text Input

To simplify things a bit, here's a basic rundown of how Android's Accessibility works. A developer creates an Accessibility Service that subscribes to various Accessibility Events that are sent by the system to the Service depending on whether or not certain criteria are met. When all Services are disabled under Settings –> Accessibility, Android does not collect or send any Accessibility Events. But when the user starts enabling Accessibility Services, Android will begin monitoring and collecting only those Accessibility Events that the Accessibility Service requests. For example, an Accessibility Service that subscribes to the Accessibility Event TYPE_WINDOW_CONTENT_CHANGED will be notified by the system every single time that a change in the current window occurs. Another Accessibility Event called TYPE_VIEW_CLICKED fires off every single time the user clicks on a button of some kind.

Android Accessibility Demonstration. In this video, I've enabled the app Tasker to monitor for changes in the Window title. This requires enabling Tasker's Accessibility Service. You can replicate this by creating a new profile in Tasker with the 'Event' context set to 'Variable Set' and choosing %WIN as the variable to monitor. In total, this approximately 1 minute video captured 107 changes in the current Window.

These kinds of Accessibility Events occur with great frequency during normal user interaction. So imagine what happens when a user enables multiple Accessibility Services that request high frequency Accessibility Events be fired off. That's right – lag. To mitigate this, developers can more narrowly define what kinds of Accessibility Events their Service should react to and in what context, such as the ability to limit the Service to only react when in certain apps or to limit the polling period between Events. But other than that the amount of overhead generated by an Accessibility Service is dependent mostly on what kinds of Accessibility Events it subscribes to. In essence, not every Accessibility Service will cause lag. A single Accessibility Service that requires a high frequency Event may cause lag, especially if said Service is coupled with another Service that requires another high frequency Event to be monitored.


Diving Deep into Accessibility with APK Teardowns

As you could tell from the video posted above, an Accessibility Service that monitors for changes in the window content can result in fairly noticeable changes in UI performance due to the sheer amount of captured Accessibility Events fired off by the system. However it's quite difficult to determine exactly how much overhead is caused by a particular Accessibility Service. Monitoring LogCat will generally get you nowhere, as Accessibility Events are only printed to LogCat if the developer of the Accessibility Service chooses to do so. Thankfully, the daddy of all Android Accessibility Services, AutoInput, does exactly that. And the LogCat output is exactly as messy as you would imagine.

AutoInput's Accessibility Service AutoInput Tasker Plugin AutoInput Window Monitor AutoInput LogCat Output

AutoInput doesn't hide the truth from us. The overhead caused by the app can be quite enormous depending on what Events you monitor. But this overhead is necessary for the app to function. In order for AutoInput to intercept every key press, every screen gesture, every UI update, and every button press, it needs to monitor the respective Accessibility Events. Without these Events, AutoInput cannot hook into the system and provide the almost unlimited UI automation that it currently allows for. Thus, all of AutoInput's functions make perfect sense within the context of Accessibility. But for other apps, we need to look a bit deeper to understand how their Accessibility Services are handled.

An Accessibility Service's attributes are defined in an XML resource file within the APK. Therefore, we can perform an APK teardown on an app with an Accessibility Service to figure out the Service's attributes. Each app functions differently, so I will try to explain how their Service's attributes relates to the specific function it performs.

Native Clipboard

native-clipboard

Native Clipboard is my go-to when it comes to clipboard managers. If you are looking for a highly customizable clipboard manager, Native Clipboard is a pretty great app. It even has an Xposed Module component to allow you to long-press on the 'Paste' button to bring up the clipboard manager! Unfortunately, if you don't have access to the Xposed Framework (such as every user on Nougat) then you'll have to settle for enabling the Accessibility Service which will allow you to double-tap on any text input to bring up the clipboard manager. Here's what that entails.

  <?xml version="1.0" encoding="utf-8"?>  <accessibility-service android:description="@string/access_decs"  android:accessibilityEventTypes="typeViewClicked|typeViewFocused|typeViewLongClicked|typeWindowStateChanged"  android:accessibilityFeedbackType="feedbackGeneric"  android:notificationTimeout="100"  android:accessibilityFlags="flagReportViewIds|flagRetrieveInteractiveWindows"  android:canRetrieveWindowContent="true"  xmlns:android="http://ift.tt/nIICcg" />  

Native Clipboard's Accessibility Service requests firing off an Accessibility Event each and every time that a view is clicked, long-clicked, focused, or if there is a change in the window state. Without having access to the source code, I cannot say exactly how Native Clipboard works, but it's likely that Native Clipboard waits for the Window state to indicate that the soft keyboard is currently open, and then it monitors for taps on the input field. The app has a polling period of 100ms, so that is definitely quick enough to react basically immediately to changes in the soft keyboard visibility as well as double taps. This could result in some UI overhead whenever the user is using the soft keyboard to type any text, potentially resulting in lag.

Greenify

greenify

Next up is everyone's favorite battery saver, Greenify. Greenify uses Accessibility Events to power its non-root functions.

  <?xml version="1.0" encoding="utf-8"?>  <accessibility-service android:description="@string/accessibility_service_description"   android:settingsActivity="com.oasisfeng.greenify.accessibility.AccessibilitySettings"   android:accessibilityEventTypes="typeAnnouncement|typeNotificationStateChanged|typeWindowStateChanged"   android:accessibilityFeedbackType="feedbackGeneric" android:notificationTimeout="0"   android:accessibilityFlags="flagReportViewIds"   android:canRetrieveWindowContent="true"  xmlns:android="http://ift.tt/nIICcg" />  

It uses changes in the Window State to determine when the phone's screen has turned off, and it requires that you delay the lock screen activation by changing an option in security settings. Greenify will also receive Events of type Announcement or Notification State changed, the latter which is unnecessary on Android 5.0+ devices thanks to the Notification Access feature. It will, however, still receive these events regardless of that fact. Greenify should not cause much overhead by itself, but the possibility remains.

Nova Launcher

nova-launcher

Probably the most popular third-party launcher app on the market, Nova Launcher is an excellent example of an app using an Accessibility Service with minimal to no overhead. The only reason for the Service's existence is to aid certain devices in performing gestures.

  <?xml version="1.0" encoding="utf-8"?>  <accessibility-service android:description="@string/accessibility_service_description"   android:accessibilityEventTypes=""   android:packageNames="com.teslacoilsw.launcher"   android:accessibilityFeedbackType=""   android:notificationTimeout="10000"   android:canRetrieveWindowContent="false"  xmlns:android="http://ift.tt/nIICcg" />  

As you can see, there is no Accessibility Event defined in the XML file. All that is mentioned is the name of a package – Nova Launcher. What happens here is a workaround for certain devices for which Nova Launcher's gestures do not work. This service will provide Nova Launcher all Accessibility Events fired off from only within Nova Launcher. It sounds odd, but it's apparently a way to fix Nova's homescreen gestures if your device doesn't work with them. Since this only requests Events from Nova itself, the Service poses very little overhead.

LastPass

lastpass

Finally, perhaps the most infamous Accessibility Service which causes lag (probably due to its immense popularity) – LastPass. The issue of lag within LastPass is so noticeable that the company has an official FAQ page describing the issue. As the FAQ states, there is nothing you can do about the lag except to disable the Service. Why does LastPass's Service seem so egregious when it comes to lag? Let's take a look at the Service's attributes.

  <?xml version="1.0" encoding="utf-8"?>  <accessibility-service android:description="@string/accessibility_service_description"   android:accessibilityEventTypes="typeViewFocused|typeWindowContentChanged"   android:accessibilityFeedbackType="feedbackGeneric"   android:notificationTimeout="200"   android:accessibilityFlags="flagReportViewIds"   android:canRetrieveWindowContent="true"   android:canRequestEnhancedWebAccessibility="true"  xmlns:android="http://ift.tt/nIICcg" />  

The truth is, there's nothing really out of the ordinary with LastPass's Service. It only requests two Event types to monitor – TYPE_VIEW_FOCUSED and TYPE_WINDOW_CONTENT_CHANGED. It does this because it needs to know when an app/webpage's content changed/comes into focus, and then it retrieves the current window content to look for any password input fields. But since the service constantly does this on two extremely frequently firing Accessibility Events, it results in lag. That's the unfortunate truth.


Living with the Lag

When we first read that Google was closing bug reports about Accessibility lag because the feature was "working as intended", we were just as perplexed and upset as many of you. But rather than accept the explanation at face value, we decided to look into the matter ourselves to determine the truth. So when the Googler on the bug report page said this:

Hi this issue is persistent over Android releases, Also there will always be an additional lag when an accessibility service is enabled. That's because the device, in addition to the standard UI, is providing a lot of information to accessibility services so they can provide an alternative user experience to those users.

We have come to understand why this is intended behavior. Apps that use Accessibility Services in a manner that was unintended by Google will always incur some performance overhead; this cost is simply necessary to provide Services with the plethora of information that Android Accessibility fires off in the background. Android's lag with Accessibility Services is not a bug, but a feature. A feature that we will have to live with unless the entire system is reworked, and I cannot imagine how that would be done to accommodate so many different feature sets from so many different apps.

At the very least, the LastPass developers would not take this sitting down. Their developers have worked with the Chromium developers to optimize accessibility support, perhaps by enabling LastPass support through the use of APIs rather than enabling an Accessibility Service. Optimizing around the overhead incurred by Accessibility Services is one possibility, but as many developers have implicitly noted on the Chromium forums, it's simply a bandaid that won't resolve the fact that unintended uses of Accessibility Services may result in lag.


Special thanks to the developer of AutoInput, joaomgcd, for answering many of my questions regarding Accessibility!



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

BlackBerry DTEK60 Spotted Online; Looks Like a Rebranded TCL 950

BlackBerry's recent decision to license manufacturing and focus on software meant that they would not be developing and manufacturing any of their future phones from that point forth. Their last device, the DTEK50, was a rebranded Alcatel Idol 4. So when images of the DTEK60 surfaced, the likeliness to the TCL 950 could not be ignored.

The images of the upcoming DTEK60 come to us courtesy of Evan 'evleaks' Blass and CrackBerry Editor Bla1ze. The phone's exterior seem all too similar to a phone recently released by TCL (known better in the western world by the name Alcatel) — the TCL 950.

Blackberry DTEK60

There are no specs provided along with the images, but since the TCL 950 is out, we can speculate on what we can expect to see on the upcoming DTEK60 since there is a good chance that BlackBerry's newest device is nothing but a rebrand with perhaps a small spec change here and there. The display on the TCL 950 is a 5.5″ FHD AMOLED display. Inside, there is a Qualcomm Snapdragon 820 SoC, along with 4GB of RAM and 64GB of storage along with expandability up to 128GB. The phone bears a 3,000 mAh battery with Quick Charge 3.0 support, and a USB Type-C port. The device also sports a convenience key on the side. The camera setup involves a 21MP Sony IMX230 with f/2.2 on the rear and a 8MP shooter with f/2.2 on the front.

The DTEK60 might deviate from the TCL 950 on the screen resolution, as the BlackBerry device has been rumored to sport a QHD display. Further, there could be changes on the storage and expandability front, but the rest of the spec is likely to remain intact, including the Snapdragon 820 SoC.

Blackberry DTEK60 Blackberry DTEK60

A listing for the DTEK60 also popped up at NCIX, a Canadian online retailer. The quoted price of the device is 699 CAD, which comes out to ~$533. The price is likely to be adjusted on a per-market basis, but this should give us a good starting point for expectations. The BlackBerry DTEK60 is not official yet, so we would still advise to take everything with a pinch of salt.

What are your thoughts on the BlackBerry DTEK60 so far? Let us know in the comments below!



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

Exploring Andromeda: A Look at the Challenges Awaiting Google’s Next Voyage

With the release of the Pixel and Pixel XL phones coming up, rumors abound that Google will be announcing a new platform based on Android enhanced by Chrome OS features, called Andromeda. Google has already started bringing features from one to the other (Android apps in Chrome OS, seamless updates in Android, etc.), but questions remain about how Google intends to gain market share in the laptop and convertible market.

Chrome OS already has a substantial niche in the education sector thanks to the low price of Chromebooks and their ease of use, but how will Google grow beyond that? How can Google use that niche to expand Andromeda to other markets? What can Google do to compete against existing laptop operating systems with long histories of native program libraries and users growing accustomed to the design language?

Pixel C Edge ImageDeveloper support is vital, and a major problem is going to be app development. Right now Android Studio does not run on Android or Chrome OS, but it will need to run on Andromeda if Google wants to succeed. With Chrome OS, everything is web focused, so you didn't really need a development environment for running anything locally (and development tools are limited). With Android, historically most devices weren't powerful enough to develop on, and developers typically didn't want to develop on smaller screens anyway. With Andromeda though, Google is targeting an expansion of Chrome OS's market share, by bringing Android (with some Chrome OS features added in) and the ability to run Android apps to the laptop and 2-in-1 markets. Full Android apps on, potentially, your primary laptop. If Google doesn't port Android Studio to Andromeda, they will be severely handicapping themselves. They would essentially be telling any developer that can only afford one computer "Too bad. We won't let you develop for our laptops while on our laptops." They would be directly harming the ability of the developers most interested in their products to develop for those products.

Google needs to make sure that it is easy for developers to get involved in the Andromeda development scene, and Google does know this. They've been pushing how easy it is to get into Android development for a long time (which is a big part of why they chose Java), and it has gone a long way towards helping grow the Android platform, and especially the platform's app store. They just need to keep pushing for it, they need to keep improving ease of use. Android Studio needs to be easy to install and update on Andromeda. It needs to run smoothly despite the low power processors (compared to what you see in workstations) that you will often see in Andromeda devices. It needs to be something that the students who will likely make up a significant portion of Andromeda's initial customer base will want to use.

Google has made it possible to run Android apps in Chrome OS, and that is helping to bridge the gap and ease transition pains by unlocking a huge repertoire of apps for the new OS, from both Chrome OS and Android, but even that doesn't come close to scratching the surface of the huge libraries that Windows, OSX, and Linux have (especially with Google discontinuing Chrome Apps). Andromeda will need substantial development to fill in the gaps, as even being able to do 90% of what people use their laptops for still means that for many people, Andromeda will not be enough.

office-suites-and-standardizationMany companies have ported versions of their desktop software to Android for cheap or for free (like Adobe Photoshop and Microsoft Word), albeit often with a reduced feature set, but will they block that version on laptops/hybrids in order to prevent cannibalizing their own desktop sales? What will Google have to do to convince them to target that market?

A developer may not want to sell a game on Andromeda laptops for $10, when the Windows/Linux/etc. version of the same game goes for $30. Some developers might split out the phone and laptop/tablet versions of the app into two different Play Store listings in order to try to keep their prices consistent in some ways. Andromeda will have a limited program library as it is, Google cannot afford to let it splinter.

If the program library problems weren't enough, Google is also going to have to deal with the issue of inter-OS compatibility if they want Andromeda to take off in the corporate world. Microsoft Office tends to not play nice with other office suites, often having issues with both opening and saving files in industry standard formats (which Microsoft claims to follow, but that's a different article), and Microsoft Office is extremely widespread. Google themselves have issues with it as well, with Google Drive sometimes struggling to export documents that won't lose key formatting when imported elsewhere. If Google wants to break Microsoft's hold on the office environment, they're going to have to take a shot at it from multiple levels. Just having a fantastic product alone isn't enough (as LibreOffice/OpenOffice has proven). Google needs to push for ODF support and for public adoption of open standards (especially at a governmental level), something that The Document Foundation has actually been seeing a lot of success with lately. Google needs to fight to ensure compatibility.

They also need to move beyond the web-first mentality of Chrome OS. We're already seeing it to some extent with the rumors of increased storage in the Pixel devices, and the increased focus on offline content (alongside Google's recently increased attempts to drive usage of their cloud services through things like Assistant). Most notably, earlier this week Google launched YouTube Go for offline YouTube viewing in India.

Alongside the launch, Sundar Pichai published an op-ed in The Economic Times where he talked about why there has been such a shift in Google's behaviour. Specifically, he noted that while many of the data saving features that Google has introduced have been targeted at India, they have become immensely popular elsewhere when brought to other markets. It appears to have made Google realize that much of the world (even in Europe and North America) isn't as ready for online-only content as Google may have hoped.

"Moreover, we learned the issues Indians may have with connectivity, and data constraints can be universal. We dreamed up Maps Offline for India, but people in the United States and Europe are finding it just as useful. Simply put, solving for India is inspiring new Google innovations. … new things built for and inspired by India that move us a few steps towards the vision of making the benefits of the open Internet available for everyone."

Sundar Pichai

That only begins to scratch the surface of the issues that Google will have to face if they want Andromeda to succeed. The user interface will be a huge issue as well. Just stretching phone apps up to laptop sizes won't cut it. Google needs to prepare for users using a mouse and keyboard. You have to look no further than Windows 8 (and even current Desktop vs. Metro Apps) to see a whole crop of issues that pop up with focusing too much one way or the other. Large tiles in the center of the screen and gestures swiping in from the top and sides of the screen are fine for a tablet, but don't work so well on a laptop with a mouse and keyboard. Small little icons to click on around the edges of the screen are great for a precise mouse and keyboard, but don't work so well for our larger fingers and a touchscreen.

Windows 10 Split Keyboard With Nuit Blanche HTC 10 Long Exposure Toronto BackgroundProper button placement can be defined extensively by what is easy to reach. On a phone, that might be the entire screen. On a tablet, the center may be harder, but the edges and bottom are still fine. On a touchscreen laptop, you may want everything in the bottom corners to minimize how far off the keyboard you have to raise your hand. User Interface is affected by device form factor, and we need to take it into account if we want Andromeda to succeed. We may need drastically different UIs when in laptop and tablet mode (much in the way Windows 10 handles it), which kills a large portion of the benefit of having one device (as it creates two UIs that the average person needs to learn for the same device). That's not to say that it can't be done well. If there are two separate UIs many people will choose to use it in desktop mode at all times (and vice versa), as both UIs will have their own unique benefits and restrictions. Yes, a single UI that is a happy medium is often ideal, but two UIs that coexist can be just fine, as long as they work together in sensible ways.

Speaking of touchscreens, not every Chromebook has a touchscreen, and if Google wants to continue to target some Andromeda devices to the absolute low-end of the market (like the sub-$100 Chromebook), then some Andromeda devices likely won't have touchscreens either. It can be an absolute pain to use certain Android apps without a touchscreen, and developers will get flak for it. It's just a reality, some apps won't play well with a mouse and keyboard, and unfortunately some developers will prevent Andromeda laptops from installing their app in order to avoid those negative reviews. We will need an extension of Material Design with clear guidelines on how to best target both touchscreen and mouse + keyboard devices. It shouldn't be a requirement, but there hopefully will be some information to assist developers in preparing their apps for this change (and Google might have to change their stance a bit on tablet specific apps as a result).

" Unless Google intends for every Andromeda laptop to be ARM based, they need to work on getting developers to port their native apps to x86, and binary translation doesn't cut it"

The hardware platform itself also has some issues. Unless Google intends for every Andromeda laptop to be ARM based, they need to work on getting developers to port their native apps to x86 (and potentially MIPS) as well as ARM. Binary translation just doesn't quite cut it, although we have seen some improvements over the years. The NDK and Vulkan are very powerful tools, and will only become more so if Andromeda really takes off and we see Andromeda in increasingly powerful computers.

Support for Android apps definitely will help with Andromeda's initial program library, but it is a double edged sword. Having no historical program library is a huge issue, but having Android app compatibility might just result in developers not coding for Andromeda, and instead just creating Android phone apps and hoping that it will work (or work out) on laptops as well (we already see this mentality with Android tablets). We saw this with BlackBerry 10, we saw this with Windows Phone, and we've seen this fail many times over. While we have to hope for the best, the general idea is one that has been tried, and which has failed over and over again. You can argue that it came down to implementation, but we'll have to wait to see if Google can find the right implementation. Even without the issues associated with using apps designed for touchscreens on computers with a mouse and keyboard, Android already has substantial issues with scaling. Using apps on tablets often has an insane amount of wasted screen space, frequently because developers (even Google) either don't fully understand how to use Android's scaling functionality, or don't care enough about tablets to implement it properly (given the current Android tablet market, we can't really blame them). If Google wants solid app support for laptops, then they need to find a major way to encourage developers to actually prepare their apps for the different device styles. They need a format that will work well on the desktop, and they need to push it heavily.

Screenshot of Top Paid Apps and Games Tabs on Play StoreMore importantly, Google will need to succeed somewhere that they have failed numerous times already. If Google wants Andromeda to take off, they will need to properly curate the Play Store. They'll need to make it possible to search specifically for mouse + keyboard optimized applications and touchscreen optimized applications. Phone optimized UIs, tablet optimized UIs, and laptop optimized UIs (which, admittedly goes against the "just let everything scale" mentality, but the differences between laptops and phones makes it necessary, as was mentioned above). People need to be able to find programs that actually work for them, and right now the process of discovering new apps on the Play Store is pretty bad. The "Top Charts" are filled with freemium games, flashlight apps, and even the occasional task killer still (the latter of which is outright harmful to your phone), although thankfully Google finally separated out apps and games into separate charts in August. You still see some embarrassing things while browsing the store though, like an app with a logo that was almost a palette swap of a competitor's logo making it into the top 40.

If Google cannot manage the Play Store more efficiently, then they may have to open up their platform a bit if they want to succeed. It seems unthinkable, but perhaps if Andromeda wants to compete against the vast library of programs available on other platforms, Google may have to target compatibility with the existing GNU/Linux software environment. Currently there are some very distinct differences between Android/Linux and GNU/Linux which prevent GNU/Linux programs from running on Android/Linux (namely the near complete lack of GNU libraries, although there are ways to install them if you are rooted), but the gap is shrinking. Google for years has been pushing code upstream where applicable (even if only just to reduce their code maintenance costs), and has been merging in features and potentially code in from Chrome OS (which uses a substantial amount of GNU libraries and can run standard GNU/Linux programs with a bit of tweaking). We have also seen Google go to great lengths to improve the graphics stack for Android (even dropping support of some devices at the last minute in order to add a requirement for Vulkan or OpenGL ES 3.1 in Android 7.0). While the stated reason is to improve the quality of games on Android and to make porting games to Android easier, it also closes the gap between Android/Linux and GNU/Linux a bit. With the recent major push by Valve to improve the Linux gaming experience, we actually see a decent number of AAA titles on Linux now, and having support for Dota 2 or Rocket League could make a huge difference for how the average user views the software situation on Andromeda. Then again, I don't think Google would be too happy to see an Andromeda devices shipping with an alternative program store like Steam.

Original IBM PC 5150That being said, there may be unintended benefits to merging code from Chrome OS into Android, and from the mentality shift that it brings. Android has struggled for years with some inherent differences between the platform and the traditional desktop environment. Namely, the fact that phones never had an "IBM PC Compatible" moment meant that there is a gross lack of standardization for both boot procedures and driver support. Google is trying to fix that to some extent with solutions like device trees, but a lot of work still needs to be done. Chrome OS is interesting in that a large portion of the devices using it ship with coreboot (as does the Android based Pixel C, which ships with a Chrome OS style boot image), which helps provide a specific platform for the OS to target. With Andromeda potentially following Chrome OS's model for its boot image rather than Android's, we may see Google attempt to leverage the existing Chrome OS infrastructure to make Android installations more modular, especially if the leaks that Andromeda will eventually be able to be installed on virtually any future x86, MIPS, or ARM device are true (which would tie in well with Google and Sony's recent work to provide enhanced theming support, which OEMs can use to apply their customizations).

"Two years of support just doesn't cut it. The support life of personal computers needs to be measured in many years, not a few months."

And that may be a key factor for Andromeda's future success. If Google can get carriers, OEMs, stores, foundries, etc. all onboard with the idea of having a single underlying OS (like Microsoft and Apple's products) with strong theming support and substantial extensibility (to allow OEMs to include their tweaks and enhancements), then they can completely change the update dynamic. No more waiting for OEMs and carriers to finish tweaking the update.

When Google pushes out the latest update, it would be immediately available for your device (assuming your device has the appropriate driver support of course, which will be highly dependant on development efforts like device trees). You could go and install it right away, and still keep your OEM themes as they would (theoretically) be built to hook into stable theming APIs.

Intel Pentium MMX Processor Logo 1993 to 1999For phones, that is nice, but for tablets and laptops it is crucial. You (hopefully) don't constantly carry your laptop with you at all times and don't drop it from time to time. Tablets and laptops are expected to last a lot longer than a phone is. Replacing them every two years isn't quite as common, and two years of support just doesn't cut it. The support life of personal computers needs to be measured in decades (best case scenario), not months. There are computers that launched in 2003 that can still run Windows 10, and don't even get me started on the ridiculous support life that Linux has (earlier this year Debian finally dropped support for Intel's 586 processors from 1993, and they're still going to be providing security patches for it until 2020). If Google wants to be taken seriously in the the laptop market (beyond the niche of Chromebooks), they are going to need an update model that is drastically different from what we see on Android, and Andromeda might just be bringing it.

Looking back knowing that Google has been working towards this since 2013, it appears almost obvious that many features were added with this shift in mind. From the substantial expansion of multi-user in 2014 (that never really was pushed after being expanded), to split screen, to the return of full support for SD cards, and a whole list of changes. Google has silently been preparing for this for a while, and hopefully that preparation will translate into platform success.

Remix OS Small LogoGoogle really need to look at where other OSes have failed to get an idea of what pitfalls this OS needs to avoid, but they also need to look at where other OSes have succeeded. Remix OS and Windows 10 give a feeling for how to succeed in the convertible space, and they draw from both ends of the spectrum in order to do it. Large buttons that are easy to hit and easy to read, but not without being huge tiles like in Windows 8. Interfaces that are friendly to both scrolling with your fingers, and scrolling with a mouse. Taking the existing UX that people are used to, and tweaking it a bit to fit touch screen implementation, rather than a complete overhaul.

Google definitely has their work cut out for them with Andromeda, but we may just see something amazing come out of it.



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

samedi 1 octobre 2016

EU Plans to Fine Google for Anti-Competitive Android Practices

The road in Europe is looking to become rockier for Google and Alphabet, as the antitrust proceedings against the company in the European Union are looking to culminate with a hefty fine and some drastic changes.

As per a new report published by Reuters, EU's antitrust regulators are planning to order Google to stop offering financial incentives to smartphone makers to pre-install Google Search exclusively. This order is a result of the investigation against the search giant where it was accused to using Android and its dominance to shut out rivals, thus creating an anti-competitive environment.

The regulators plan to order Google to "halt payments or discounts" to OEMs given to pre-install Play Store along with Google Search. They also want to prevent the pre-installation of proprietary apps as well, if it restricts the ability to use competing OSs based on Android. The report mentions that Google "cannot punish or threaten" companies for not complying with its conditions.

In addition to all of this, EU also plans to levy a large fine because the anti-competitive practices are still ongoing from the time they went into effect in January 2011. The level of the fine would be "sufficient to ensure deterrence". The penalty could be based on European AdWords revenue, Google Search product queries, Play Store app purchases and AdMob's in-app advertisements.

These fines and orders are related to the anti-competitive nature of Android preloaded with the Play Store. There is one more investigation underway for the Search end of things, where Google is accused of favoring its own sopping service over those of its rivals. This could in turn be a separate fine, but the decision for this would be decided at a later stage.

All in all, the next few months could impact Google and Alphabet right in the pocket. The antitrust order also has the potential to change the Android landscape as Google would be forced to let off its aggressive hold on Android and loosen its stance on derivative forks. Companies like Samsung would then be open to test out Google Play Store-less routes like Amazon did with its Fire lineup of phones and tablets, without giving up the freedom to also continue with providing Android with the Play Store.

What are your thoughts on these purported fine and orders? Do you think Google deserves a fine for their anti-competitive practices? Let us know in the comments below!



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

The OnePlus 3 and Axon 7 Show Affordable Phones Don’t Have to Come at the Cost of Software Updates

In the past, purchasing a "mid-range phone" meant a plethora of compromises: weak after-sales support, few and far between updates, and compromised feature sets (and, more often than not, an ugly user interface). OnePlus devices, too, had questionable software and update support.

The OnePlus 2 took ages to get a proper marshmallow update. The OnePlus X still doesn't have one one. However, things seem to be changing for the better as thus far with the OnePlus 3, the situation has vastly improved. In fact, while writing this article OnePlus sent out another OTA to version 3.2.7. Heading over to their official site, there are 9 software versions available for the 3. Some of these are community builds – essentially  refined betas – but the experience of installing them is pretty straight forward, and they do build upon previous versions with optimizations and great features (such as the increasingly-popular scrolling screenshot) that enhance the UX without taking away from what makes it pleasant. We've had our worries regarding the merging of the Hydrogen and Oxygen OS platforms through a unified development team, but OnePlus was quick to listen to criticism and ease concerns by announcing Oxygen OS would keep a Stock Android look in its System UI.

OnePlus 3 Update Screen

OnePlus 3 Update Screen

My most recent experience with updating my OnePlus 3 truly impressed. My device was on OxygenOS 3.2.4 rooted, with Xposed installed, a custom DPI, and TWRP as the recovery — if you are used to these features, you know how they can often complicate updates. However, OxygenOS detected my device was rooted and downloaded the full version of 3.2.6, rather than just the OTA. My OnePlus 3 then rebooted into TWRP and updated to 3.2.6 with no data loss, no hiccups, no booting issues. This process did replace TWRP with the standard OnePlus recovery, but it's rather simple to get back to TWRP anyway.

These frequent updates to the OnePlus 3 have added key features that the community asked for from day one such as RGB mode, but also the aforementioned  scrolling screenshots, improved auto-brightness, updated 4K recording codecs (as we pointed in our OnePlus 3 review, they were a mess around the time of launch!), and improved RAM management (which, again, is something we determined to be pretty bad early on). The OnePlus 3 is also up to date with the September 1st security patches, and all of this makes for a device that has improved every few weeks in tangible ways. We aren't sure if the merging of both ROM teams has already begun or if this continuous support is a product of that, but it's terrific to see this effort either way, and OnePlus has so far redeemed its poor reputation on this front with this product cycle.

One of the OnePlus 3's biggest competitors has to be the ZTE Axon 7, which actually carries some higher specifications in some areas, while still being in the same bracket. Thus far, after purchase support and updates have also been impressive as well.

Axon 7 Update Screen

Axon 7 Update Screen

The Axon 7 just received an update to version B27, and this is the third update my Axon 7 has received since launch. The phone's only been out for a few months and we've already have seem updates help with UI tweaks, battery life improvements, camera enhancements, and the latest September 1st security patches. ZTE has been communicative and responsive on their official forums regarding updates and features additions, too, which is always a plus.

Of note to our audience here at XDA is that ZTE has also come up with a method of unlocking the bootloader. There are some caveats such as losing the warranty, but the having the option is great and ZTE should be commended for at least giving us the option (albeit the OnePlus 3 is certainly much better in its warranty policy for us tinkerers). More manufacturers providing this option is good for the community, but we would really like to see this not come at the cost of losing the warranty.

Overall, both of these devices offer terrific hardware packages and incredible value for the money. There was a time when a $400 device would also come with a cost of reduced software support, infrequent updates, or drastically-reduced features (quantity or execution). The OnePlus 3 and the Axon 7 both seem to be defying this trend and, in turn, changing our expectations. Both of these devices right now have the latest security patches and both are running 6.0.1, and we have no issues recommending either device based on support thus far. It's especially reassuring to know that these companies have improved their communication channels with their respective communities, and are throwing us enthusiasts a bone or two by allowing us to tinker and customize.

Both devices should also get Android Nougat in due time, with the recent OnePlus Software AMA giving us some vague hints regarding its development. In any case, the openness of the OnePlus 3 means you can already try out Nougat on the device. Features like Dash Charging are also now available on custom ROMs, and OnePlus has also stated that they plan on finding ways to improve the camera quality on custom ROMs too, so the custom ROM experience is bound to only get better on this device. But if you don't want to go that route, OnePlus' official support is better than ever with promising prospects (assuming they keep their word), with more than just promises: tangible results in the form of feature-packed updates, and internal changes to accommodate for a new software model for faster updates. Devices like the OnePlus 3 and the Axon 7 are so far squashing the notion that more affordable devices come at the cost of software support, another item in the long list of preconceptions that these "flagship-killers" challenge when it comes to their price. At a time where updates are some of the biggest headaches in the Android world for a multitude of reasons, we couldn't be happier about that.

How important is software support to you? Share your opinion below!

 



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