Samsung has been working hard to get back on their feet after the whole defective battery issues with the Galaxy Note 7. The last couple of months have not been good to the South Korean tech giant, but things are finally starting to level out for them. It did seem like business was going to get rocky for Samsung again when a replaced Galaxy Note 7 caught fire, but that looks to be an isolated incident and not another batch of defective batteries.
Two weeks ago we started seeing safe Galaxy Note 7 units appear in major US wireless carrier stores. This first started with AT&T, but then branched out to the other major US carriers as well. Just like in the United States, Samsung had also suspended sales in other countries as well. The company just resumed sales of the Galaxy Note 7 in their home country of South Korea on October 1st as they had previously announced.
Along with resumed sales, Samsung is also offering South Korean customers a 50% discount on screen repairs for those who buy the device in October. One would suspect that customers would be worried about buying the Galaxy Note 7 right now, but this doesn’t seem to be the case. In South Korea, a smartphone is said to be a “hit” if they are able to sell 10,000 units per day and the Note 7 has surpassed this benchmark.
The Korea Herald is reporting that since sales of the Galaxy Note 7 have resumed, Samsung has been able to sell 30,000 units on Saturday and Sunday. This has to be a relief for Samsung, but the real test is if they will be able to keep up with these sales numbers, especially outside of their own turf in South Korea. Dedicated Samsung fans would have likely bought the Note 7 anyway, but it’ll be interesting to see if the smartphone has staying power after the reputation that has been building around it.
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.
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!
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.
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 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 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.
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
Next up is everyone’s favorite battery saver, Greenify. Greenify uses Accessibility Events to power its non-root functions.
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
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.
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
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.
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’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.
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.
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
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
