Yesterday, the final Android Nougat developer preview for us to play with began rolling out. At the bottom of the announcement blog post, Google announced that part of their Android engineering team would be hosting an AMA (Ask Me Anything) over on Reddit’s /r/AndroidDev subreddit (aimed towards developers).
The AMA went live earlier today and was quickly filled to the brim with questions. Since the AMA was geared towards developers, the users on the subreddit took the opportunity to field pertinent questions regarding developing for Android Nougat. Here is a summary of everything we’ve learned from the Reddit AMA.
Index of Topics:
- Night Mode and Theming
- Doze Mode
- Material Design
- Nougat Password Reset Restrictions
- Android Bug Tracker (Page 2)
- Programming Languages for Android (Page 2)
- APIs and Fragments (Page 2)
- Android NDK (Page 2)
- Long-Term Android OS Support (Page 2)
- Bluetooth Support in the Android Emulator (Page 2)
Night Mode and Theming
Redditor Satanmymaster:
Will we see night mode in the official release of nougat? If no, please explain why. Its such a brilliant feature. At least leave it hidden as a bonus feature if you don’t think it’s ready for everyone. Thanks!
Response from AndroidEngTeam:
Alan: This one has been my pet feature for a while… So there were two “night mode” features in N DP that you might be referring to: dark theme (via -night qualifier) and screen tinting.
The former, dark theme, was a modification to Material that would automatically switch between light and dark variants based on UiModeManager’s night mode setting. Which was awesome, and I know a lot of people really liked seeing a dark theme in Settings; however, in both M and N the dark theme feature had to be reverted because of ecosystem problems. As simple as we tried to make it, implementing dark theme meant doing twice as much design work and twice as much verification that visual styling was implemented correctly. It wasn’t a good allocation of design and engineering resources. In many places, like WebView, it simply wasn’t possible to convert content to a dark theme while preserving the content author’s original intent. Leaving a half-working feature in the platform, where developers would be expected to support it, wasn’t acceptable. So I’ve had to personally kill the feature twice, and ultimately it’s been for the benefit of the platform.
HOWEVER! We were still able to launch dark theme in support library, so apps can still benefit from the super-simple -night qualifier.
The latter, screen tinting, was built on top of the display accessibility APIs introduced in M. This was another “ultimately for the benefit of the platform” issue… The feature needed serious work, both on the low-level graphics driver side to implement tinting efficiently and the high-level TwilightManager side to correctly implement automatic shifts between day and night. It wouldn’t be ready in time for N, and it wasn’t acceptable to leave a half-working feature, so we had to pull it. It have been really rewarding to see positive feedback for the feature, though, and I would love to see it in a future release.
Redditor Surge1223:
Is there a logical reason why 4-way reboot and back-to-kill as well as other community driven popular items such as allowing framework theming, as first shown by Sony, aren’t being adopted?
As a developer a I’d love to just use stock Android, but I find myself turning to the open source community because of a few critical items I find hard to believe are missing or intentionally left out as it seems, such as the aforementioned.
Response from AndroidEngTeam:
Alan: Regarding platform theming, many of Sony’s RRO changes are already merged and “in the wild.” More RRO changes are up for review in AOSP right now. It’s a big, low-level change, so it’s slow-moving. Once that’s in, we’d need to stabilize the platform themes so that OEMs have officially-supported endpoints that they can customize. Between releases, there are always a lot of changes under-the-hood to our themes and styles, which is a huge advantage when it comes to updating to whatever the latest Material spec may include, but it’s a moving target for OEMs that want to customize specific aspects of the platform’s appearance. So — definitely not anti-theming! Unless you’re talking about forcing theme modifications upon unsuspecting apps. As Adam put it, that makes developer’s lives hard by breaking guarantees made by CTS (the test suite that verifies a platform is “compatible” Android).
Adam: back to kill has a number of other issues too, part of which is that long press on back is already something reserved to apps that they can use. Overall we want to make sure that power user features aren’t in the way such that they would confuse others, but we try to keep a good balance. I think the winds are blowing toward more power user shortcuts though, double-tap on the Overview button in N is a good example.
Dianne: Theming was actually part of the original resources design from before Android 1.0, so it is definitely not something we fundamentally oppose! It has, however, been a lower priority than a lot of other things, and as Adam and Alan say once you start digging into it seriously as a platform feature, there are a tremendous number of complicates that must be addressed for how this interacts with apps and platform maintenance. This is a good example of a common situation where a feature done on top of AOSP can require a tremendous amount of additional design work to turn it into something that can be adopted into core AOSP and thus supported as a core platform feature.
Doze Mode
Redditor s73v3r:
What are the plans for Doze going forward? Will there be any plans for using more of a light touch instead of using the sledgehammer that is currently used?
Also, to wake from Doze currently, it takes messages sent from GCM. Are there any plans to decouple this from Google services, for those who do not want to or cannot use Google servers to relay their messages?
Response from AndroidEngTeam:
Adam: Expect the sledgehammer to get bigger, not smaller.
Paul: But seriously, why do you want a light touch? We’re trying to make it save as much battery as possible without breaking any use cases.
Dianne: Apps that have special requirements to bypass (most) doze restrictions can do that by being on the “disable battery optimizations” list. The system is designed around discouraging apps from being on that list, since each of those apps is another opportunity to deeply harm the user’s battery life. For any app running on a device with Google Play services, we very much want them to be using GCM to wake up the device since this is generally much more power efficient, and for that reason we will continue to push in the direction of apps getting on that rather than relying on their own implementation.
Material Design
Redditor RandomOrganicMatter:
How long will Material Design last?
Response from AndroidEngTeam:
Adam: if it starts growing mold we’ll need to look at a replacement.
Alan: No, we’d re-grout the areas between the whitespace. I think it would be fine. But seriously, I think there’s plenty of room for Material to continue to grow and adapt. We’ve seen new widgets introduced, specs refined and changed. From a framework perspective, it’s been interesting to figure out how to evolve the spec without breaking the design of existing Material apps.
Chet: One element about Material that might help its longevity is its reliance on plain, white assets that can then be tinted according to theme colors that make sense for the app. This strikes me as a more future-proof approach than some bold, trendy look like, say, birch-wood-grained that is going to look bold and dated soon.
Rachel: All this to say, Material Design isn’t going away anytime soon. The fundamentals – motion, expressing your brand, clean and clear layouts – are good bets for long-lasting behaviors you’d want any app to follow.
Redditor infinitesimus:
Animations ate a big part of material design but barring the most basic (private…) animations, most of the cool things Google wants us to do with MD aren’t provided out of the box; leading to several developers having to write their own animations and behaviors from scratch. Do you feel this sentiment is valid, if so, if there something the team has planned to make such transitions easier to make/use?
Response from AndroidEngTeam:
Chet: On the last animation/Material Design question: We provided the Material Design Library (part of the Support Library) as a partial response to this exact issue; helping developers with implementing various pieces of Material Design more easily. We do plan to add more capabilities like that to continue that trend. Animations can be tricky and very specific to how the applications are structured. We plan to keep improving the animation and transition capabilities of the platform, but some behaviors and effects are best built from scratch by the app developers.
Nougat Password Reset Restrictions
Redditor chiraggalani25:
Hey AndroidEngTeam,
In Android Nougat Dev Previews, reset password restrictions for device admins now apply to profile owners. Device admins can no longer use DevicePolicyManager.resetPassword() to clear passwords or change ones that are already set. Device admins can still set a password, but ONLY when the device has no password, PIN, or pattern.
This issue even exists if the device is not an ‘Android for Work’ device. Hence, it doesn’t have device or profile owner set. Then, how can a 3rd party application set a new password over existing password. Is there a workaround available for non ‘Android for work’ devices?
Issue report: http://ift.tt/2a7ttDY
I agree it is a security measure. But, what if the user wants to set a particular app as device/profile owner which is not a malware and is a genuine app downloaded from the Google Play store?
Response from AndroidEngTeam:
Dirk: This behavior (i.e. a device admin not being able to reset device password) is by design. For non-Android for Work devices, the only way to set a password is if the device has no password/PIN/Pattern.
Continue to page 2, where we cover details that are catered towards developers.
from xda-developers http://ift.tt/29M3Tms
via IFTTT
Aucun commentaire:
Enregistrer un commentaire