LightBlog

lundi 3 octobre 2016

Win an Honor 8: 4GB RAM, Dual-Camera, Premium Design

We're back with another Honor 8 contest, and like before, it's open to all countries! You can enter the contest in numerous ways. Each point you earn is considered an entry, so the more points you earn, the higher your chances are of winning. As a reminder, the Honor 8 is the current flagship from Honor and sports dual-cameras, USB Type-C with fast-charging, a Kirin 950 CPU with 4GB RAM, and a 5.2″ 1080p display. We will pick the winner around during the week of October 17. Good luck!

Win a New Honor 8!

  Honor 8 XDA Review   Honor 8 Forums

  Win Stuff from Honor



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

Facebook Announces Messenger Lite For Older Devices and Emerging Markets

Facebook just announced Facebook Messenger Lite, a new low-resource version of Facebook Messenger (much to the disdain of the developers of Lite Messenger for Facebook), joining Facebook Lite in their portfolio.

Facebook Lite LogoFacebook Messenger Lite is a cut down version of Facebook Messenger, weighing in at under 10 MB. It is designed to be fast to download (even on slower data connections) and fast to open, and includes many of the basic Facebook Messenger features like "messaging, sending and receiving photos and links, and receiving stickers." However no mention was made in the announcement of calling, location sharing, read receipts, or various other features, some of which have likely been cut in order to get down to the smaller APK size that they are targeting. Facebook also made extensive mention of how Facebook Messenger Lite was designed with a focus on slow and unreliable network connections, and how it will help expand Facebook Messenger into markets that it previously couldn't reach.

David Marcus, Facebook's VP of Messaging Products, stated that Messenger Lite was created "for people, who still own older Android devices (think 2009-2011) that have less available 'disk' space, memory, and lower performing CPUs, and that often run on lower bandwidth connections", rather than for people buying current entry-level phones. Back when dual core processors were just starting to hit the market, batteries were commonly around 1400 mAh, Samsung hitting the 1 GHz mark was considered impressive, and many phones were shipping with storage amounts measured in Megabytes. Phones like the Motorola Droid, the HTC Desire, and the Samsung Galaxy S II. Technology has changed substantially since then, and it can be easy to forget how different those devices were from current flagship phones like the Moto Z Force, the HTC 10, or the Samsung Galaxy Note 7 if you haven't seen them in a while, but there are still people out there that use older devices, and Facebook wants to see those people using their communication platform.

Facebook Messenger Lite

Facebook is aware of the reputation that Facebook Messenger has as being a bit of a resource hog, and were very careful in their launch announcement to avoid undercutting their full Facebook Messenger offering. While having people on Messenger Lite is nice for Facebook, they would prefer that people use the full Messenger offering to avoid splintering which parts of the userbase can use which features with each other. They know that there is a risk of people switching from Facebook Messenger to Facebook Messenger Lite, especially as many people have been asking for improvements in Facebook Messenger's resource usage for quite a while now (which was redoubled by Facebook's removal of messaging functionality from the mobile website earlier this year), and are stressing that Facebook Messenger Lite is targeted for early smartphones, the likes of which are becoming increasingly rare in the Western world. As a result, Facebook may decide to permanently keep country restrictions on Messenger Lite similarly to what they are currently doing with Facebook Lite.

Facebook Messenger Lite will be initially launching in Kenya, Tunisia, Malaysia, Sri Lanka, and Venezuela, with promises of more countries being added shortly. It will be interesting to see what countries Facebook Messenger Lite comes to, and what steps Facebook takes to promote it there. Messenger Lite looks like it could be a solid product, but Facebook will need to take some steps to advertise it if they want people to actually use it (although their methods with Facebook Lite seem to have been fairly successful, with it reaching a couple hundred million installs already).

It also will likely only launch on Android, as there are limited numbers of smartphones on other OSes in developing markets (although many companies like Samsung, Microsoft, Apple, and Mozilla have been attempting to make inroads into the market), and Facebook extensively mentioned Android in their announcement.

What are your thoughts on Facebook's strategy of Lite apps? Do you think it is a wasted effort with early smartphones being on their way out? Or is it a smart strategy to target markets that Facebook Messenger cannot reach, especially for something social where every user matters? Let us know in the comments below!



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

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 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.

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