LightBlog

jeudi 26 mai 2016

Recent MotoMod Leak Gives Us a Look Into the Future of Modular Phones

It appears modularity is in this season, folks. When the Phonebloks concept was released a few years ago, it made a tremendous impact about how we look at phones and their upgrade process.

Not long after, Google and Motorola took over the Phonebloks idea and announced Project Ara, their take on a modular smartphone. After the initial steam subsided, the market seemed to flat line. Very little news came from the project, and many considered the idea of a modular phone all but lost.

Cue 2016, and LG. With the release of the LG G5 and the unveiling of its modular port, talks of modularity were all the rage again. However, the phone was launched with a very limited module set on release, and ultimately was overshadowed by the non-modular competing flagships. Jump toGoogle I/O 2016, and the announcement of a future release of a consumer ready Project Ara. Modularity has become the hot topic once again, and it seems Motorola is next in line to take a bite off the modularity pie.

Now fast-foward to Evan Blass. Notorious Twitter leaking artist @evleaks has recently treated the Internet with two looks at the future of both Motorola and the concept of modular smartphones. The first leak is off three different color variations of possible future Droid phones. These models look eerily similar to the leaks of a redesign of Moto phones from earlier this year, which came with much criticism.

Moto Z

The next leak gives us a look at what Evan refers to as “MotoMods”. These appear as what some have speculated to be Motorola’s modular attachments to the new Droid and Moto Z lineups. They appear as full back plates, as opposed to the chin clips on the LG G5. It is speculated that the attachments will connect magnetically, or through pin ports as seen on the Droid phone leak. The modules look more robust, offering a full on extra camera, and two other backs could be an expanded battery and textured grip with a kickstand.

MotoMod

Will these potential Moto phones/add-ons finally bring modular phones into the mainstream spotlight? Or are they doomed to be overshadowed by the non-modular competition just like the G5? Let us know what you think in the comments below!



from xda-developers http://ift.tt/1NPy4uW
via IFTTT

OnePlus 3 Arrives on TENAA Website in Full Spec and Design Glory

The OnePlus 3 launch is right around the corner, as the device has now made its way over to Chinese certification authority TENAA. This gives us possibly the best look at the finalized product before its official launch.

The OnePlus will likely sport a metallic unibody construction, which is reminiscent of the HTC One M-series of devices. The TENAA images do not mention the construction, but the previous leaks do line up well with the TENAA listing.

OnePlus 3

OnePlus 3 OnePlus 3 OnePlus 3

The front of the OnePlus 3 is clutter-free in typical OnePlus fashion, with the camera sensor on the left and a fingerprint scanner on the bottom. Although the TENAA images do not give a proper shape and form to the earpiece, sensors and capacitive buttons, these should be present as well. The fingerprint scanner on the OnePlus 3 has rounder edges than one on the OnePlus 2, but this is likely just an aesthetic change and should not affect its usability.

The left side of the device bears the volume rocker, and an alert slider above it. It is good to see OnePlus still sticking with the slider, as it gives one more hardware switch to control aspects of the device. The right side of the phone bears the SIM card tray and the power button.

The back of the OnePlus 3 features the rear camera setup and the OnePlus logo, along with visible plastic antennae bands for aiding radio reception. Interestingly, there is only a single tone LED flash, and laser autofocus is absent as well. It is to be seen how OnePlus markets the camera when a few of last years features will no longer be available on the upcoming flagship. Also, there is a noticeable camera hump, as is evident from the side shots.

The TENAA listing also mentions several specifications. The phone modelling is likely to be OnePlus A3000. The device will be sporting a 5.5″ FHD AMOLED display, with the device dimensions being 152.6 mm x 74.6 mm x 7.3 mm and weighing 160 g. Powering the phone will be a Qualcomm Snapdragon 820 clocked at 2.15GHz and flanked by 4GB of RAM. You will get 64GB of internal storage, although the listing does not mention anything regards the microsd expandability. The rear is a 16MP shooter, while the front will be a 8MP shooter. The phone will get its juice from the 3000 mAh battery, which is most likely non removable. For its operating system, the phone will launch with Android 6.0.1 Marshmallow, which is against the leaked screenshot but inline with our prediction. The OnePlus 3 will be available in Black, Gold and Light Grey color options.


So, what is the confidence level of the TENAA listing? Since this is China’s certification authority, information from the website does not classify as leak, but is a representation of the finished product. Data flowing from TENAA listing has a 100% track record, and this particular listing is representative of the final OnePlus 3.

There still remain a few questions that remain unanswered by the TENAA listing. The listing makes no mention of any 6GB RAM model of the device, one that was rumored to be in the works a while back. The pricing of the listed device is also unknown, but it is likely to hover around the $349 price mark, give or take. The official launch event of the OnePlus 3 is also not yet confirmed, although murmurings in the tech circles point to an unconfirmed date around June 14 2016. We also do not know whether the OnePlus 3 will follow along the infamous and widely hated invite system from OnePlus, although Carl Pei did joke about it on his Twitter a few days ago.

The answers to all of these questions will be answered in the upcoming days. Here’s hoping that OnePlus actually manages to kill some flagships in 2016.

What are your thoughts on the OnePlus 3? Do you look forward to purchasing it? Let us know in the comments below!



from xda-developers http://ift.tt/20FT8oR
via IFTTT

mercredi 25 mai 2016

Android will Soon Support the Raspberry Pi 3

About 5 weeks ago, Google created a new device tree in their AOSP repository for the Raspberry Pi 3. It’s still empty after all this time, but it did suggest that the company was working on adding Android support for the tiny ARM computer. The official Raspberry Pi 3 Twitter page has now confirmed our suspicions, so we’ll see that repo filled with code when Google is ready.



from xda-developers http://ift.tt/1WkNhqL
via IFTTT

Tutorial: Using Java 8 Features When Developing for Android N

Android N adds support for Java 8 features that developers can employ if they’re targeting Android N in their applications. If you’re interested, XDA Recognized Developer sylsau has written a tutorial to show you how to leverage these new features.



from xda-developers http://ift.tt/1OY2fk0
via IFTTT

Android Apps on ChromeOS: What Devs Need to Know for the Best User Experience

Google I/O 2016 brought many exciting announcements this year. If you’ve missed them, make sure to check our articles which recap announcements geared towards developers and those aimed at users.

We wanted to cover one particularly interesting I/O session in more details, though: “Bring Your Android App to Chrome OS”, presented by Luis Héctor Chávez, an engineer in the Chrome OS team. While we’ve already covered the announcement from a user’s viewpoint, we also wanted to provide a recap of this I/O session aimed at developers.

The motivation behind this feature is rather clear: getting Android apps on Chrome OS is a good way for developers to get more users, while providing Chromebook users with more apps. It’s a win-win situation… assuming it doesn’t take more time than it’s worth (spoiler alert: it’s actually pretty easy!).

Previous Options

Supporting both Android and Chrome OS was not an easy task in the past, and developers basically had two options at first:

  • The first was to write a Chrome OS app, which would result in two separate code bases (a huge task for the initial port and double the work for future updates).
  • The second was to use HTML5 apps. While this would make it easy to run on Chrome OS and Android, it wouldn’t feel native on the latter and wouldn’t be able to take full advantage of the Android platform.

Android on Chrome OS: Previous Options

Since late 2014, using the App Runtime for Chrome (ARC) also became an option. However, it was still a rather involved process: file system access was restricted and could cause problems for some apps, not all Google Play Services were supported, extra work was required to use certain features such as in-app payments, and developers still had to publish their app separately on the Chrome web store.

The Chrome OS team has therefore been working on a better solution for developers.

The New Approach

Android on Chrome OS: New Sandboxing Technique

Chrome OS will soon have a new sandboxing mechanism that will allow users to run Android apps directly while maintaining a high level of security, performance and compatibility. This is done by running the whole Android system (initially Android Marshmallow). Android apps will also support multi-window (though not quite the same as Android N’s — more info in a bit), and users will be able to change their size, maximize and minimize them.

Android on Chrome OS: Multi-Window

In order to give developers time to prepare and for further testing, this feature will initially be disabled by default and will be available in the Chrome OS development channel in June, the beta channel in August, and the stable channel in September.

Initially supported devices are the Acer Chromebook R11/C738T, Asus Chromebook Flip and the Google Chromebook Pixel (2015). You can check the full list here.

What developers need to do is simple: your apps should show up directly in the Play Store on Chrome OS in most cases, without requiring you to do any changes to your code (except to tweak the experience on Chrome OS, of course). In fact, there are no new APIs for you to learn or use to support Chromebooks.

Just-in-time binary translation is also provided so that ARM apps can run on x86 Chromebooks with no extra work required from your part.

Your Android apps will work like Chrome OS apps: your apps are integrated in the launcher/shelf, notifications will show up like native notifications, and clipboard and sign-in info are shared between the two OSes. The hardware and input methods also just work with no extra effort from your part. It just works. Seamlessly.

Best Practices to Follow for Developers

That being said, there are some best practices you’ll want to follow to make sure your apps show up on all supported Chromebooks, and run well on them.

  • Remember that Chromebooks come with a keyboard and a trackpad, which means you’ll want to test your apps with a keyboard+mouse setup and try to optimize the user’s experience. For example, you might want to add hotkeys support in productivity apps, or offer better control schemes in games.
  • Not all Chromebooks have a touchscreen. By default, Android apps require one — but your app probably does not actually need touch features. Make sure to declare that the touchscreen feature is not required in your AndroidManifest.xml:
    <uses-feature android:name="android.hardware.touchscreen"
                  required="false" />
    

    Without this change, your app will not appear in the Play Store on Chromebooks without touch support.

  • The same applies to other hardware features. Chromebooks have no GPS for instance, but they can still provide a coarse location via WiFi which might be enough for your app. Don’t require hardware that might not be available unless it’s actually needed.
  • Some software features are not available on Chrome OS:
    • android.software.input_methods
    • android.software.app_widget
    • android.software.live_wallpaper
    • android.software.home_screen
  • Other features are also unsupported as Chrome OS is the device manager:
    • android.software.device_admin
    • android.software.managed_user
  • For the above three points: remember that your app will not show up on the Chrome OS Play Store if it requires an unsupported feature.
  • Multi-window support is not the same as Android N’s (yet! The Android implementation in Chrome OS will eventually be updated from M to N). Instead, Chrome OS will simply make your app switch between layouts it most likely already supports: landscape (similar to the Nexus 7), portrait (similar to the Nexus 5) and maximized (your app just fills up the whole screen).Android on Chrome OS: Multi-Window Implementation
    • No changes to the activity life cycle model are made: only one app can have focus at a time, but multiple apps can be visible at once. Make sure to start/resume rendering when your app gains focus (in Activity#onResume())`__), and pause rendering when it loses focus (in Activity#onPause()) in order to conserve battery. Of course, for some apps, you’ll want to make sure you’re doing the opposite instead. An obvious example is video playback apps, where you wouldn’t want playback to stop when your app loses focus but is still visible.
    • The Low Memory Killer will take into account the Z-order, killing apps that are further in the background first if necessary.

     

    • Window controls are offered to the user, allowing them to switch between the different layouts.
      • IAndroid on Chrome OS: Multi-Window Controlsf necessary, declare the correct android:screenOrientation activity attribute in your manifest to only use supported orientations.
      • You’ll also want to make sure you’re handling runtime changes correctly, especially screenWidthDp, screenHeightDp and densityDpi. Remember that changing orientation will be like changing the device, so the width and height won’t simply flip — they’ll be totally different values. If you’re handling orientation changes yourself, don’t forget to invalidate and load the correct resources after the orientation changes, since you’re effectively changing devices and might therefore have to use different size-specific resources (e.g. tvdpi to xhdpi).
      • Launching a new task (Intent#FLAG_ACTIVITY_NEW_TASK) means it’ll render in a new window. Don’t launch activities in a new task if you don’t want that.
      • Respect onPause as discussed above.
  • If possible, implement support for Backup & Restore. This is not necessary but will provide a better experience to users.
  • Keep in mind that Chromebooks can be shared between multiple users (e.g. for educational purposes: a Chromebook might be shared by several students), and be mindful of the local storage you use. An account (along with its local storage) might be deleted at some point, for instance.

Last but not least, even though Chrome OS will ship with Marshmallow initially, it’s still a good idea to be ready for N, as that will bring more usability features such as resizeable activities, cross-app drag&drop and a mouse cursor API.

Luis shared some useful resources to prepare for that (before finishing the session with a demo):



from xda-developers http://ift.tt/1WUp6zR
via IFTTT

YU Open Sources its OS for YUREKA, YUPHORIA and YUNIQUE

Micromax subsidiary YU has open sourced its base OS found on its devices, namely YUREKA, YUPHORIA and YUNIQUE. Contributions to this source code will be curated and mixed with other sources like AOSP and other 3rd party ROMs to create one manifest for YU devices.



from xda-developers http://ift.tt/1ONMl6m
via IFTTT

The Lenovo Moto G4 Signals the Fall of a Kingdom

On a fateful day in November 2013, an Android giant released a humble device, one which could not stand up to the knights and princes of the Android world. Little did they expect that this humble little device to become the best selling smartphone the company had ever seen.

moto_G_photo4Such was the tale of the Motorola Moto G. Right now, in 2016, if you looked at the specs without knowing this was the Moto G, you’d glance away without the slightest thought. After all, a 4.5″ HD display, a Snapdragon 400 SoC, 1GB of RAM and 8GB of non-expandable storage aren’t specs that we would recommend to anyone this year. To give an estimate of the market situation back then, the Qualcomm variant of the Samsung Galaxy S4 was released in March-April 2013, bearing a 5″ FHD display, a Snapdragon 600 SoC, 2GB RAM and 16GB of expandable storage. We are comparing apples to oranges since the S4 was a flagship and the Moto G was on the opposite end, but this comparison is to just give you a glimpse on how low the Moto G really was.

But surprisingly, despite the specs which weren’t too exciting, the Moto G did excite customers. And a lot of them too. This wasn’t solely because the phone had specifications that one part of the market wanted. It was because this part of the market was willing to get all these specs at the puny $179 price it commanded for the 8GB variant. The Moto G landed in the Indian market with an expectedly inflated price of Rs. 12,499 (close to $195 at prior conversion rates), but the phone was still lapped up by the market.

The magic behind the Moto G was not what individual specs it brought to the table, or how much it costed. The value behind the phone that propelled it to popularity was the sum total of all of its points: You get some good specs at prices you do not mind, you get the trust behind the brand Motorola along with all of its customer support systems, and you get a clean and unburdened OS with solid performance, battery life, and the promise of future updates. The public loved it.

Granted, the Moto G did not entirely capture the market. It had stiff competition from all quarters, as it dipped its toes in the saturated entry level markets that was flooded with cheap devices that did nothing. Everyone claimed to do the same few things, but Motorola went a step ahead and actually did what they claimed. The phone was launched with Android 4.3 Jellybean in November 2013, and was updated to Android 4.4 Kitkat in around December 2013 (Kitkat was released in October 2013). Then the phone was updated to Android 5.0 Lollipop in around January-February 2015 (Android 5.0 was released in November 2014, Android 5.1 was released in March 2015). There was a delay in the last few updates, but Motorola gave one more parting gift to the original Moto G with Android 5.1.1 being released in July-September 2015.

Although the updates were not the quickest, the big point about them was that they were present. From 4.3 to 4.4 to 5.0 to 5.1, the Motorola Moto G saw three major software jumps — that is three more than what one would expect from other phones in that price segment. A manufacturer that cared for its starting lineup beyond their warranty period was rare, and the Moto G was certainly very lucky in this regard.

With the Moto G2 and the Moto G3, Motorola attempted to follow along the same set of strategies that worked for it in the first time. They avoided reinventing the wheel, sticking with similar designs, similar (but upgraded) specs, similar pricing and the similar promise of update. The screen was bumped up to 5″ while still being HD, and the processor was swapped over for the Snapdragon 410 for the G3. Other areas of improvements were the camera and a bump in battery, along with the introduction of IPX7 rating for water resistance. The G series knew its place in the market and was perfectly fine in competing for it only.

Motorola-Moto-G4-press-840x479

The Moto G4 however, has landed in a time of further heightened competition. And to add to its woes, the G4 barely upgrades over the G3 in key areas. The SoC includes another cluster of A53’s but improves on the GPU with the Adreno 405 (vs Adreno 306). Part of this improvement is then offset by the bump in resolution, with the 5.5″ FHD display being more taxing to run than a 5″ HD display. The base storage does see a bump up to 16GB, and so does the battery with a 3000 mAh pack powering it all up. But again, some of this gain will be offset by the display.

The camera setup on the Moto G4 remains the same. The design is an area which is subjective to every person, but objectively, the phone changes up significantly from its predecessors. And worse, the phone actually regresses on the IPX7 rating, losing a feature that had contributions to its success in tropical climate markets like India. The starting price of the Moto G4 was not revealed during the event, but it is likely to hover around the Rs. 12,499 ($185) mark, which is close to the start points of the predecessors.

So why is the Moto G4 a poor (or poorer) deal? The answer to this question lies in how the G series shaped up the market in the recent years. Other OEMs have stepped their game majorly, or exited out of the market quietly. You get a lot more options in the market right now, and several of them offer a better proposition in various areas.

If you are willing to settle for MediaTek, you get a vast array of Chinese devices with SoC’s ranging from the MT6753’s all the way to the Helio X10 (slightly outdated) and the Helio X20 (which MTK pits as a competitor to current flagship SoCs). If you do need a Snapdragon SoC, you can find several other phones in the market with the the Snapdragon 615, which is close to the Snapdragon 617 in performance. You can even get yesteryear flagship SoC’s like the Snapdragon 801 in this price range, which is still competitive for the starter level.

If you are still not content, you can find devices with the Snapdragon 650 and Snapdragon 652 within the price of the Moto G4. The 650 duo is second to none other than the 820-flagship SoC in terms of raw performance and thermal management, so you can get an unbeatable package while still being around the same price points.

And we haven’t even touched areas like a metallic body or a fingerprint sensor — areas that other devices have been forced to evolve into to keep up with the market trends.

The Moto G4 stands no chance of repeating any of its predecessors success, and a decent chunk of blame also goes onto the Moto G4 Plus. The G4 Plus has been given the preferred sibling treatment from Lenovo, bearing the improved camera setup (according to reviews so far) that other phones in the market may not be able to match. The very existence of the Moto G4 Plus spells doom for the Moto G4 — there remains little reason to buy the Moto G4 anymore. The price difference is a farce, as you do not get the same value out of the package.

The Moto G4 signals the fall of a kingdom: a kingdom built purely on the value to the consumer. The G4 can not size up to the success of its predecessors, and it definitely can not compete with the competition. The prospects are weak as of now, and they will only worsen as more and more phones are released with better specs and lower prices. Lenovo does need to seriously reconsider the pricing of the Moto G4 (and the Moto G4 Plus, by extension) if they wish to repeat the success that they tried to purchase.

What are your thoughts on the Moto G4? How do you feel the phone works against the current competition? Will the Moto G4 Plus affect and dilute the G-series lineup? Let us know your thoughts in the comments below!

 Feature image: MathiasZamecki



from xda-developers http://ift.tt/1Z0dBEo
via IFTTT