Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator&page=3' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Feed aggregator
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

Hardening the media stack

Android Developers Blog - Mon, 05/16/2016 - 22:04

Posted by Dan Austin and Jeff Vander Stoep, Android Security team

To help make Android more secure, we encourage and reward researchers who discover vulnerabilities. In 2015, a series of bugs in mediaserver’s libstagefright were disclosed to Google. We released updates for these issues with our August and September 2015 security bulletins.

In addition to addressing issues on a monthly basis, we’ve also been working on new security features designed to enhance the existing security model and provide additional defense in-depth. These defense measures attempt to achieve two goals:

  • Prevention: Stop bugs from becoming vulnerabilities
  • Containment: Protect the system by de-privileging and isolating components that handle untrusted content

Prevention

Most of the vulnerabilities found in libstagefright were heap overflows resulting from unsigned integer overflows. A number of integer overflows in libstagefright allowed an attacker to allocate a buffer with less space than necessary for the incoming data, resulting in a buffer overflow in the heap.

The result of an unsigned integer overflow is well defined, but the ensuing behavior could be unexpected or unsafe. In contrast, signed integer overflows are considered undefined behavior in C/C++, which means the result of an overflow is not guaranteed, and the compiler author may choose the resulting behavior—typically what is fastest or simplest. We have added compiler changes that are designed to provide safer defaults for both signed and unsigned integer overflows.

The UndefinedBehaviorSanitizer (UBSan) is part of the LLVM/Clang compiler toolchain that detects undefined or unintended behavior. UBSan can check for multiple types of undefined and unsafe behavior, including signed and unsigned integer overflow. These checks add code to the resulting executable, testing for integer overflow conditions during runtime. For example, figure 1 shows source code for the parseChunk function in the MPEG4Extractor component of libstagefright after the original researcher-supplied patch was applied. The modification, which is contained in the black box below, appears to prevent integer overflows from occurring. Unfortunately, while SIZE_MAX and size are 32-bit values, chunk_size is a 64-bit value, resulting in an incomplete check and the potential for integer overflow. In the line within the red box, the addition of size and chunk_size may result in an integer overflow and creation of buffer smaller than size elements. The subsequent memcpy could then lead to exploitable memory corruption, as size + chunk_size could be less than size, which is highlighted in the blue box. The mechanics of a potential exploit vector for this vulnerability are explained in more detail by Project Zero.

Figure 1. Source code demonstrating a subtle unsigned integer overflow.

Figure 2 compares assembly generated from the code segment above with a second version compiled with integer sanitization enabled. The add operation that results in the integer overflow is contained in the red box.

In the unsanitized version, size (r6) and chunk_size (r7) are added together, potentially resulting in r0 overflowing and being less than size. Then, buffer is allocated with the size specified in r0, and size bytes are copied to it. If r0 is less than r6, this results in memory corruption.

In the sanitized version, size (r7) and chunk_size (r5) are added together with the result stored in r0. Later, r0 is checked against r7, if r0 is less than r7, as indicated by the CC condition code, r3 is set to 1. If r3 is 1, and the carry bit was set, then an integer overflow occurred, and an abort is triggered, preventing memory corruption.

Note that the incomplete check provided in the patch was not included in figure 2. The overflow occurs in the buffer allocation’s add operation. This addition triggers an integer sanitization check, which turns this exploitable flaw into a harmless abort.

Figure 2. Comparing unsanitized and sanitized compiler output.

While the integer sanitizers were originally intended as code hygiene tools, they effectively prevent the majority of reported libstagefright vulnerabilities. Turning on the integer overflow checks was just the first step. Preventing the runtime abort by finding and fixing integer overflows, most of which are not exploitable, represented a large effort by Android's media team. Most of the discovered overflows were fixed and those that remain (mostly for performance reasons) were verified and marked as safe to prevent the runtime abort.

In Android N, signed and unsigned integer overflow detection is enabled on the entire media stack, including libstagefright. This makes it harder to exploit integer overflows, and also helps to prevent future additions to Android from introducing new integer overflow bugs.

Containment

For Android M and earlier, the mediaserver process in Android was responsible for most media-related tasks. This meant that it required access to all permissions needed by those responsibilities and, although mediaserver ran in its own sandbox, it still had access to a lot of resources and capabilities. This is why the libstagefright bugs from 2015 were significant—mediaserver could access several important resources on an Android device including camera, microphone, graphics, phone, Bluetooth, and internet.

A root cause analysis showed that the libstagefright bugs primarily occurred in code responsible for parsing file formats and media codecs. This is not surprising—parsing complex file formats and codecs while trying to optimize for speed is hard, and the large number of edge cases makes such code susceptible to both accidental and malicious malformed inputs.

However, media parsers do not require access to most of the privileged permissions held by mediaserver. Because of this, the media team re-architected mediaserver in Android N to better adhere to the principle of least privilege. Figure 3 illustrates how the monolithic mediaserver and its permissions have been divided, using the following heuristics:

  • parsing code moved into unprivileged sandboxes that have few or no permissions
  • components that require sensitive permissions moved into separate sandboxes that only grant access to the specific resources the component needs. For example, only the cameraserver may access the camera, only the audioserver may access Bluetooth, and only the drmserver may access DRM resources.

Figure 3. How mediaserver and its permissions have been divided in Android N.

Comparing the potential impact of the libstagefright bugs on Android N and older versions demonstrates the value of this strategy. Gaining code execution in libstagefright previously granted access to all the permissions and resources available to the monolithic mediaserver process including graphics driver, camera driver, or sockets, which present a rich kernel attack surface.

In Android N, libstagefright runs within the mediacodec sandbox with access to very few permissions. Access to camera, microphone, photos, phone, Bluetooth, and internet as well as dynamic code loading are disallowed by SELinux. Interaction with the kernel is further restricted by seccomp. This means that compromising libstagefright would grant the attacker access to significantly fewer permissions and also mitigates privilege escalation by reducing the attack surface exposed by the kernel.

Conclusion

The media hardening project is an ongoing effort focused on moving functionality into less privileged sandboxes and further reducing the permissions granted to those sandboxes. While the techniques discussed here were applied to the Android media framework, they are suitable across the Android codebase. These hardening techniques—and others—are being actively applied to additional components within Android. As always, we appreciate feedback on our work and welcome suggestions for how we can improve Android. Contact us at security@android.com.

Categories: Programming

New Practical Product Ownership Workshop Dates

I just posted the dates for the next Practical Product Ownership workshop: Deliver What Your Customers Need. It starts Aug 23, 2016.

You need this workshop if:

  • You are having trouble doing everything in your PO role, you might be trying to do too much. See Product Manager, Product Owner, Business Analyst?
  • You are having trouble deciding how to organize your backlog, roadmap, and everything.
  • How to value the items you do organize. We discuss Cost of Delay and seven other possibilities to rank the items.
  • How to help people articulate the problems they want the team to solve, not the solutions.
  • And much, much more.

We meet twice a week for six weeks. Our first meeting is a 90-minute teaching call, where I teach and you ask questions. We meet later that week for a 60-minute coaching call, where you bring your problems, concerns, and challenges.

I estimate you will have about 60-90 minutes of homework every week. Any other questions? Email me.

Categories: Project Management

Android N Developer Preview 2, out today!

Android Developers Blog - Mon, 05/16/2016 - 01:47

Posted by Dave Burke, VP of Engineering

Last month, we released the first Developer Preview of Android N, to give you a sneak peek at our next platform. The feedback you’ve shared to-date has helped us catch bugs and improve features. Today, the second release in our series of Developer Previews is ready for you to continue testing against your apps.

This latest preview of Android N fixes a few bugs you helped us identify, such as not being able to connect to hidden Wi-Fi networks (AOSP 203116), Multiwindow pauses (AOSP 203424), and Direct Reply closing an open activity (AOSP 204411), to name just a few. We’re still on the hunt for more; please continue to share feedback, either in the N Developer Preview issue tracker or in the N preview community.


What’s new:

Last month’s Developer Preview introduced a host of new features, like Multi-window, bundled notifications and more. This preview builds on those and includes a few new ones:

  • Vulkan: Vulkan is a new 3D rendering API which we’ve helped to develop as a member of Khronos, geared at providing explicit, low-overhead GPU (Graphics Processor Unit) control to developers and offers a significant boost in performance for draw-call heavy applications. Vulkan’s reduction of CPU overhead allows some synthetic benchmarks to see as much as 10 times the draw-call throughput on a single core as compared to OpenGL ES. Combined with a threading-friendly API design which allows multiple cores to be used in parallel with high efficiency, this offers a significant boost in performance for draw-call heavy applications. With Android N, we’ve made Vulkan a part of the platform; you can try it out on supported devices running Developer Preview 2. Read more here. Vulkan Developer Tools blog here.
  • Launcher shortcuts: Now, apps can define shortcuts which users can expose in the launcher to help them perform actions quicker. These shortcuts contain an Intent into specific points within your app (like sending a message to your best friend, navigating home in a mapping app, or playing the next episode of a TV show in a media app).

    An application can publish shortcuts with ShortcutManager.setDynamicShortcuts(List) and ShortcutManager.addDynamicShortcut(ShortcutInfo), and launchers can be expected to show 3-5 shortcuts for a given app.

  • Emoji Unicode 9 support: We are introducing a new emoji design for people emoji that moves away from our generic look in favor of a more human-looking design. If you’re a keyboard or messaging app developer, you should start incorporating these emoji into your apps. The update also introduces support for skin tone variations and Unicode 9 glyphs, like the bacon, selfie and face palm. You can dynamically check for the new emoji characters using Paint.hasGlyph().

New human emoji

New activity emoji

  • API changes: This update includes API changes as we continue to refine features such as multi-window support (you can now specify a separate minimum height and minimum width for an activity), notifications, and others. For details, take a look at the diff reports available in the downloadable API reference package.

  • Bug fixes: We’ve resolved a number of issues throughout the system, including these fixes for issues that you’ve reported through the public issue tracker. Please continue to let us know what you find and follow along with the known issues here.

How to get the update:

The easiest way to get this and later preview updates is by enrolling your devices in the Android Beta Program. Just visit g.co/androidbeta and opt-in your eligible Android phone or tablet -- you’ll soon receive this (and later) preview updates over-the-air. If you’ve already enrolled your device, you’ll receive the update shortly, no action is needed on your part. You can also download and flash this update manually. Developer Preview 2 is intended for developers and not as a daily driver; this build is not yet optimized for performance and battery life.

The N Developer Preview is currently available for Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, and Pixel C devices, as well as General Mobile 4G [Android One] devices. For Nexus Player, the update to Developer Preview 2 will follow the other devices by several days.

To build and test apps with Developer Preview 2, you need to use Android Studio 2.1 -- the same version that was required for Developer Preview 1. You’ll need to check for SDK components updates (including build tools and emulator system images) for Developer Preview 2 -- see here for details.

Thanks so much for all of your feedback so far. Please continue to share feedback, either in the N Developer Preview issue tracker or in the N preview community. The sooner we’re able to get your feedback, the more of of it we will be able to incorporate in the next release of Android.

Categories: Programming

SPaMCAST 394 – Yves Hanoulle, Lessons From Coaching Children

SPaMCAST Logo

http://www.spamcast.net

Listen Now

Subscribe on iTunes

The Software Process and Measurement Cast 394 features our interview with Yves Hanoulle.  Yves returns to the Software Process and Measurement Cast to discuss his experiences as a coach with CoderDojo Ghent which brings coding and life lessons to children in Ghent, Belgium. We also explored how Yves has been able to incorporate the lessons he has learned volunteering into his day job. This is a fun interview that has a profound message about our obligation to the future.

This is great interview to come back from vacation to edit and deliver!

http://traffic.libsyn.com/spamcast/SPaMCAST_394__Yves_Hanoulle_Lessons_From_Coaching_Children.mp3

Yves’s Bio:

Yves Hanoulle started working in IT in 1994.  He has worked as software support, developer, team lead, trainer, agile coach, change artist, first follower, thought jockey.  These days he calls himself Creative Collaboration Agent.

Yves believes that IT is mainly about working with people. A skill that can never be learned enough. Mr Hanoulle is deeply involved in many communities including starting the book “Who is agile”  together with a team of 20 people. There are now multiple local country spin offs of the book (we talked about this project near the end of the interview)

Yearly Yves spends 10 to 20% of his revenue on training and books so that he stays at the forefront of thought on software development.

Since 2005, he has worked as coach or trainer for a wide range of firms across the globe.

Connect with Yves at:
Twitter: @yveshanoulle
LinkedIn: https://www.linkedin.com/in/yveshanoulle

 

Re-Read Saturday News

We continue the read Commitment – Novel About Managing Project Risk by Maassen, Matts, and Geary.  Buy your copy today and read along (use the link to support the podcast). This week we tackle chapter four, which delves into visualization of work, staff liquidity and a focus on outcomes. Visit the Software Process and Measurement Blog to catchup on past installments of Re-Read Saturday.

 

Next SPaMCAST

The next Software Process and Measurement cast will feature an essay on productivity metrics: the good, the bad and the ugly.  We will also feature columns from Kim Pries and Gene Hughson.  Also, I hope to have news about a new columnist joining the SPaMCAST family and more!

 

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

SPaMCAST 394 – Yves Hanoulle, Lessons From Coaching Children

Software Process and Measurement Cast - Sun, 05/15/2016 - 22:00

The Software Process and Measurement Cast 394 features our interview with Yves Hanoulle. Yves returns to the Software Process and Measurement Cast to discuss his experiences as a coach with CoderDojo Ghent which brings coding and life lessons to children in Ghent, Belgium. We also explored how Yves has been able to incorporate the lessons he has learned volunteering into his day job. This is a fun interview that has a profound message about our obligation to the future.


This is a great interview to come back from vacation to edit and deliver!

Yves’s Bio:
Yves Hanoulle started working in IT in 1994. He has worked as software support, developer, team lead, trainer, agile coach, change artist, first follower, thought jockey. These days he calls himself Creative Collaboration Agent.

Yves believes that IT is mainly about working with people. A skill that can never be learned enough. Mr. Hanoulle is deeply involved in many communities including starting the book “Who is agile” together with a team of 20 people. There are now multiple local country spin-offs of the book (we talked about this project near the end of the interview)


Yearly Yves spends 10 to 20% of his revenue on training and books so that he stays at the forefront of thought on software development.
Since 2005, he has worked as coach or trainer for a wide range of firms across the globe.

Connect with Yves at:
Twitter: @yveshanoulle
LinkedIn: https://www.linkedin.com/in/yveshanoulle

Re-Read Saturday News
We continue the read Commitment – Novel About Managing Project Risk by Maassen, Matts, and Geary. Buy your copy today and read along (use the link to support the podcast). This week we tackle chapter four, which delves into the visualization of work, staff liquidity and a focus on outcomes. Visit the Software Process and Measurement Blog to catch up on past installments of Re-Read Saturday.

Next SPaMCAST
The next Software Process and Measurement cast will feature an essay on productivity metrics: the good, the bad and the ugly. We will also feature columns from Kim Pries and Gene Hughson. Also, I hope to have news about a new columnist joining the SPaMCAST family and more!

Shameless Ad for my book!
Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management

Learning Through Research

Herding Cats - Glen Alleman - Sun, 05/15/2016 - 16:30

A primary learning process is research. This process is part of all science, engineering, management processes. Here's a starting point for learning how to estimate in the presence of uncertainty on agile projects.

This is the start of a literature search. Anyone making suggestions about making decisions in the presence uncertainty on agile project can start here for establishing the basis of any arguments of how and why that suggestion (conjecture possibly) is based on some set of principles. Not just anecdotal opinion.

Evm+agile estimating from Glen Alleman Related articles Debunking Failure is not an Option Project Risk Management, PMBOK, DoD PMBOK and Edmund Conrow's Book
Categories: Project Management

Pitch your product using the 3x3 framework

Xebia Blog - Sun, 05/15/2016 - 10:26
When pitching innovative product ideas, you only get between five and fifteen minutes of attention. To make those minutes count, you should be able to define your product vision in a simple but comprehensive way. For this, I’ve found this 3x3 framework technique useful. Not only is it a pretty good format for pitching your

Re-Read Saturday: Commitment – Novel about Managing Project Risk, Part 3

Picture of the book cover

Commitment

This week we are back to our read of Commitment – Novel about Managing Project Risk by Olav Maassen, Chris Matts and Chris Geary (2nd edition, 2016) .  Chapter 4 introduces more agile techniques, including work visualization, staff liquidity and a focus on outcomes.

Chapter 4 begins with Rose and Gary building an initial visualization of the process they follow to develop functionality. As a practitioner, this step is often easier said than done. Even if each person in the process knows the part they play, it is often hard to see the big picture. The act of visualization often educates the entire team and identifies gaps in the process (something that occurs later in this chapter).  After Roses uses the wall as a big kanban board, she had the team go through the process of adding all the tasks they are working on and the current state the tasks are in. Then they flagged the blocked items. The raw number of items in the process and blocked paints a startling picture. Rose recognizes that the team (at her insistence) had focused on starting tasks and features rather than getting them finished.  This is a classic IT management problem. There is an emphasis on saying ‘yes’ and starting new work mid-stream, which causes a huge amount of switching between activities when they get blocked or someone asks for status.  Both in Commitment and real life, a superior strategy is to change the focus to completing work before starting new items.  The focus of working on one thing at a time until it is complete is a common theme in lean.  Reducing the number of tasks a person is working on tends to reduce switching and waiting time which improves throughput.  This is the same principle Goldratt identified in The Goal. In Commitment, Rose has the team move all items on the wall that are not being worked on back to the “ready to be worked on” column. 

As the team gets comfortable with work visualization and being actively involved in controlling the flow their work, the board becomes the locus for conversations.  The new level of conversations and collaboration disrupts the concentration of those in cubes close to the board. Rose fixes the noise issue by giving up her office and rearranging the workspace so that the team can meet and hold discussions in her “old” office.  The new location of the team’s board allows people to congregate and interact with the board without disrupting the people trying to work.  Rose giving up her office and moving into the common team space is a reference to how Agile and lean techniques lead to a flattening of the organizational hierarchy.  Flattening is a natural outcome of moving decision-making to the team.

The type of visualization practiced in software development is a combination of process or value stream mapping and kanban.  Kanban is a pull-based method popularized by Toyota. The form suggested in Commitment, uses a similar approach described in Personal Kanban by Ken Benson (described in an upcoming SPaMCAST interview). Commitment suggests that there are three states of work shown on the kanban board: waiting, work in progress and done. Team boards often add columns for each specialty in the workflow or different classes of service (different types of work).  Kanban defines a blocked item as anything that is waiting on something or someone. Kanban focuses the team on minimizing both multitasking and constraints which maximize the flow of work to completion.

During an explanation of the new management techniques Rose is using on the project to management, Rose is confronted with a new problem.  Even though development is delivering more work to the test group, the users are not seeing the software in production. As Goldratt predicted, solving one bottleneck often allows another to emerge to take its place.  In this case testing (QA) is the new bottleneck. In order for the whole team, including QA, to understand the problem, Rose has the QA function add their work states and tasks to the kanban board. Visualization exposes the problem that development is delivering work to QA faster than they can test, creating a backup.  Now that development is actually completing work, QA has a staffing problem.  Discussions of the QA problem leads to the introduction of the concept of staff liquidity. Staff liquidity means that people move between roles to address bottlenecks. People pick up tasks based on the team’s need, their capability and capacity. In order for people to be able to move between roles to solve problems, the project needs to recognize the problem and then have spare capacity to address the problem. Organizational theory has caused most IT teams to build hardened roles into team structures, which make staff liquidity difficult. Breaking those silos requires adopting an Agile mindset both at the team and management level. The discussion of staff liquidity foreshadows a later discussion of how planning 100% utilization of personnel reduces staff liquidity.

Using the concept of staff liquidity, two senior resources, Steve and Gary hand off their work and chip in to help the QA group try to catch up.  Development’s participation in the testing process generates a realization that testers need to have more background on the software to test effectively. The testers need more information and support from business analysts (BA) to understand the specification they are receiving from the developers. Rose needs help getting her head around the BA issue.  In order to find help in the BA space, Rose reaches out to Lily who connects her with a new mentor, Magnus. Magnus challenges Rose to consider idea that what stakeholders want is value, not a project or even specific features. Magnus uses Rose’s request for tea to point out that what people ask for is what they value not specifically what they want. In the book, Rose asks for tea, not a tea bag, a cup or even hot water.  The drink is what Rose values not the components. Every team has to learn to continually ask is “where is the value?” The value does not come from inputs or outputs, but rather outcomes. Focusing the client on describing the outcomes they want allows the team a wide range of options for creating the outcome (back to real options). Commitment suggests that starting with the outcome, which is the end of the value chain, allows the team identify the assumptions they are making to deliver outcomes.  For many years, one of the mantras in IT is that the user should define what the project should deliver while the developers provided the how. The conversation on focusing on the outcome is a refinement of what most developers have known and fought for years. When Stakeholders tell you how to deliver what they need, it reduces the options and value that development can deliver. Magnus culminates his conversation with Rose by adding that a team should never commit to a course of action early unless they know why they are making that decision.  The team that only makes commitments when to know why is a team that makes commitments when they have the necessary information for making a good decision.

Chapter 4 ends with an entry from Lily’s blog.  The blog is a discussion about value and hunting value.  Hunting value requires thinking about your stakeholders and their needs (this is the concept of customer focus that Gene Hughson has discussed on the Software Process and Measurement Cast 365).  Hunting value means measuring everything.

Previous entries in the read of Commitment – Novel about Managing Project Risk 

Part 1 (Chapters 1 and 2)

Part 2 (Chapter 3)


Categories: Process Management

Re-Read Saturday: Commitment – Novel about Managing Project Risk, Part 3

Picture of the book cover

Commitment

This week we are back to our read of Commitment – Novel about Managing Project Risk by Olav Maassen, Chris Matts and Chris Geary (2nd edition, 2016) .  Chapter 4 introduces more agile techniques, including work visualization, staff liquidity and a focus on outcomes.

Chapter 4 begins with Rose and Gary building an initial visualization of the process they follow to develop functionality. As a practitioner, this step is often easier said than done. Even if each person in the process knows the part they play, it is often hard to see the big picture. The act of visualization often educates the entire team and identifies gaps in the process (something that occurs later in this chapter).  After Roses uses the wall as a big kanban board, she had the team go through the process of adding all the tasks they are working on and the current state the tasks are in. Then they flagged the blocked items. The raw number of items in the process and blocked paints a startling picture. Rose recognizes that the team (at her insistence) had focused on starting tasks and features rather than getting them finished.  This is a classic IT management problem. There is an emphasis on saying ‘yes’ and starting new work mid-stream, which causes a huge amount of switching between activities when they get blocked or someone asks for status.  Both in Commitment and real life, a superior strategy is to change the focus to completing work before starting new items.  The focus of working on one thing at a time until it is complete is a common theme in lean.  Reducing the number of tasks a person is working on tends to reduce switching and waiting time which improves throughput.  This is the same principle Goldratt identified in The Goal. In Commitment, Rose has the team move all items on the wall that are not being worked on back to the “ready to be worked on” column. 

As the team gets comfortable with work visualization and being actively involved in controlling the flow their work, the board becomes the locus for conversations.  The new level of conversations and collaboration disrupts the concentration of those in cubes close to the board. Rose fixes the noise issue by giving up her office and rearranging the workspace so that the team can meet and hold discussions in her “old” office.  The new location of the team’s board allows people to congregate and interact with the board without disrupting the people trying to work.  Rose giving up her office and moving into the common team space is a reference to how Agile and lean techniques lead to a flattening of the organizational hierarchy.  Flattening is a natural outcome of moving decision-making to the team.

The type of visualization practiced in software development is a combination of process or value stream mapping and kanban.  Kanban is a pull-based method popularized by Toyota. The form suggested in Commitment, uses a similar approach described in Personal Kanban by Ken Benson (described in an upcoming SPaMCAST interview). Commitment suggests that there are three states of work shown on the kanban board: waiting, work in progress and done. Team boards often add columns for each specialty in the workflow or different classes of service (different types of work).  Kanban defines a blocked item as anything that is waiting on something or someone. Kanban focuses the team on minimizing both multitasking and constraints which maximize the flow of work to completion.

During an explanation of the new management techniques Rose is using on the project to management, Rose is confronted with a new problem.  Even though development is delivering more work to the test group, the users are not seeing the software in production. As Goldratt predicted, solving one bottleneck often allows another to emerge to take its place.  In this case testing (QA) is the new bottleneck. In order for the whole team, including QA, to understand the problem, Rose has the QA function add their work states and tasks to the kanban board. Visualization exposes the problem that development is delivering work to QA faster than they can test, creating a backup.  Now that development is actually completing work, QA has a staffing problem.  Discussions of the QA problem leads to the introduction of the concept of staff liquidity. Staff liquidity means that people move between roles to address bottlenecks. People pick up tasks based on the team’s need, their capability and capacity. In order for people to be able to move between roles to solve problems, the project needs to recognize the problem and then have spare capacity to address the problem. Organizational theory has caused most IT teams to build hardened roles into team structures, which make staff liquidity difficult. Breaking those silos requires adopting an Agile mindset both at the team and management level. The discussion of staff liquidity foreshadows a later discussion of how planning 100% utilization of personnel reduces staff liquidity.

Using the concept of staff liquidity, two senior resources, Steve and Gary hand off their work and chip in to help the QA group try to catch up.  Development’s participation in the testing process generates a realization that testers need to have more background on the software to test effectively. The testers need more information and support from business analysts (BA) to understand the specification they are receiving from the developers. Rose needs help getting her head around the BA issue.  In order to find help in the BA space, Rose reaches out to Lily who connects her with a new mentor, Magnus. Magnus challenges Rose to consider idea that what stakeholders want is value, not a project or even specific features. Magnus uses Rose’s request for tea to point out that what people ask for is what they value not specifically what they want. In the book, Rose asks for tea, not a tea bag, a cup or even hot water.  The drink is what Rose values not the components. Every team has to learn to continually ask is “where is the value?” The value does not come from inputs or outputs, but rather outcomes. Focusing the client on describing the outcomes they want allows the team a wide range of options for creating the outcome (back to real options). Commitment suggests that starting with the outcome, which is the end of the value chain, allows the team identify the assumptions they are making to deliver outcomes.  For many years, one of the mantras in IT is that the user should define what the project should deliver while the developers provided the how. The conversation on focusing on the outcome is a refinement of what most developers have known and fought for years. When Stakeholders tell you how to deliver what they need, it reduces the options and value that development can deliver. Magnus culminates his conversation with Rose by adding that a team should never commit to a course of action early unless they know why they are making that decision.  The team that only makes commitments when to know why is a team that makes commitments when they have the necessary information for making a good decision.

Chapter 4 ends with an entry from Lily’s blog.  The blog is a discussion about value and hunting value.  Hunting value requires thinking about your stakeholders and their needs (this is the concept of customer focus that Gene Hughson has discussed on the Software Process and Measurement Cast 365).  Hunting value means measuring everything.

Previous entries in the read of Commitment – Novel about Managing Project Risk 

Part 1 (Chapters 1 and 2)

Part 2 (Chapter 3)


Categories: Process Management

Optimize, Develop, and Debug with Vulkan Developer Tools

Android Developers Blog - Sat, 05/14/2016 - 20:11

Posted by Shannon Woods, Technical Program Manager

Today we're pleased to bring you a preview of Android development tools for Vulkan™. Vulkan is a new 3D rendering API which we’ve helped to develop as a member of Khronos, geared at providing explicit, low-overhead GPU (Graphics Processor Unit) control to developers. Vulkan’s reduction of CPU overhead allows some synthetic benchmarks to see as much as 10 times the draw call throughput on a single core as compared to OpenGL ES. Combined with a threading-friendly API design which allows multiple cores to be used in parallel with high efficiency, this offers a significant boost in performance for draw-call heavy applications.

Vulkan support is available now via the Android N Preview on devices which support it, including Nexus 5X and Nexus 6P. (Of course, you will still be able to use OpenGL ES as well!)

To help developers start coding quickly, we’ve put together a set of samples and guides that illustrate how to use Vulkan effectively.

You can see Vulkan in action running on an Android device with Robert Hodgin’s Fish Tornado demo, ported by Google’s Art, Copy, and Code team:


Optimization: The Vulkan API

There are many similarities between OpenGL ES and Vulkan, but Vulkan offers new features for developers who need to make every millisecond count.

  • Application control of memory allocation. Vulkan provides mechanisms for fine-grained control of how and when memory is allocated on the GPU. This allows developers to use their own allocation and recycling policies to fit their application, ultimately reducing execution and memory overhead and allowing applications to control when expensive allocations occur.
  • Asynchronous command generation. In OpenGL ES, draw calls are issued to the GPU as soon as the application calls them. In Vulkan, the application instead submits draw calls to command buffers, which allows the work of forming and recording the draw call to be separated from the act of issuing it to the GPU. By spreading command generation across several threads, applications can more effectively make use of multiple CPU cores. These command buffers can also be reused, reducing the overhead involved in command creation and issuance.
  • No hidden work. One OpenGL ES pitfall is that some commands may trigger work at points which are not explicitly spelled out in the API specification or made obvious to the developer. Vulkan makes performance more predictable and consistent by specifying which commands will explicitly trigger work and which will not.
  • Multithreaded design, from the ground up. All OpenGL ES applications must issue commands for a context only from a single thread in order to render predictably and correctly. By contrast, Vulkan doesn’t have this requirement, allowing applications to do work like command buffer generation in parallel— but at the same time, it doesn’t make implicit guarantees about the safety of modifying and reading data from multiple threads at the same time. The power and responsibility of managing thread synchronization is in the hands of the application.
  • Mobile-friendly features. Vulkan includes features particularly helpful for achieving high performance on tiling GPUs, used by many mobile devices. Applications can provide information about the interaction between separate rendering passes, allowing tiling GPUs to make effective use of limited memory bandwidth, and avoid performing off-chip reads.
  • Offline shader compilation. Vulkan mandates support for SPIR-V, an intermediate language for shaders. This allows developers to compile shaders ahead of time, and ship SPIR-V binaries with their applications. These binaries are simpler to parse than high-level languages like GLSL, which means less variance in how drivers perform this parsing. SPIR-V also opens the door for third parties to provide compilers for specialized or cross-platform shading languages.
  • Optional validation. OpenGL ES validates every command you call, checking that arguments are within expected ranges, and objects are in the correct state to be operated upon. Vulkan doesn’t perform any of this validation itself. Instead, developers can use optional debug tools to ensure their calls are correct, incurring no run-time overhead in the final product.

Debugging: Validation Layers

As noted above, Vulkan’s lack of implicit validation requires developers to make use of tools outside the API in order to validate their code. Vulkan’s layer mechanism allows validation code and other developer tools to inspect every API call during development, without incurring any overhead in the shipping version. Our guides show you how to build the validation layers for use with the Android NDK, giving you the tools necessary to build bug-free Vulkan code from start to finish.


Develop: Shader toolchain
The Shaderc collection of tools provides developers with build-time and run-time tools for compiling GLSL into SPIR-V. Shaders can be compiled at build time using glslc, a command-line compiler, for easy integration into existing build systems. Or, for shaders which are generated or edited during execution, developers can use the Shaderc library to compile GLSL shaders to SPIR-V via a C interface. Both tools are built on top of Khronos’s reference compiler.


Additional Resources

The Vulkan ecosystem is a broad one, and the resources to get you started don’t end here. There is a wealth of material to explore, including:

Categories: Programming

Build beautifully for Android Wear’s Round Screen using API 23’s -round identifier

Android Developers Blog - Sat, 05/14/2016 - 20:09

Posted by Hoi Lam, Android Wear Developer Advocate

Android Wear is about choice. From the beginning, users could choose the style they wanted, including watches with circular screens. With Android Wear API 23, we have enabled even better developer support so that you can code delightful experiences backed by beautiful code. The key component of this is the new round resource identifier which helps you separate resource files such as layouts, dimens between round and square devices. In this blog post, I will lay out the options that developers have and why you should consider dimens.xml! In addition, I will outline how best to deal with devices which have a chin.

Getting started? Consider BoxInsetLayout!

If all your content can fit into a single square screen, use the BoxInsetLayout. This class has been included in the Wearable Support Library from the start and helps you put all the content into the middle square area of the circular screen and is ignored by square screens. For details on how to use the BoxInsetLayout, refer to the Use a Shape-Aware Layout section in our developer guide.

Without BoxInsetLayout With BoxInsetLayout
Goodbye WatchViewStub, Hello layout-round!

Developers have been able to specify different layouts for square and round watches using WatchViewStub from the beginning. With Android Wear API 23, this has become even easier. Developers can put different layouts into layout-round and layout folders. Previously with WatchViewStub, developers needed to wait until the layout was inflated before attaching view elements, this added significant complexity to the code. This is eliminated using the -round identifier:

 Pre Android Wear API 23 - WatchViewStub (4 files)

pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; } 1. layout/activity_main.xml
 <?xml version="1.0" encoding="utf-8"?>  
 <android.support.wearable.view.WatchViewStub    
     xmlns:android="http://schemas.android.com/apk/res/android"  
     xmlns:app="http://schemas.android.com/apk/res-auto"  
     xmlns:tools="http://schemas.android.com/tools"  
     android:id="@+id/watch_view_stub"  
     android:layout_width="match_parent"  
     android:layout_height="match_parent"  
     app:rectLayout="@layout/rect_activity_main"  
     app:roundLayout="@layout/round_activity_main"  
     tools:context="com.android.example.watchviewstub.MainActivity"  
     tools:deviceIds="wear"></android.support.wearable.view.WatchViewStub>

2. layout/rect_activity_main.xml - layout for square watches

3. layout/round_activity_main.xml - layout for round watches

4. MainAcitivity.java
  
 protected void onCreate(Bundle savedInstanceState) {  
   super.onCreate(savedInstanceState);  
   setContentView(R.layout.activity_main);  
   final WatchViewStub stub = (WatchViewStub) findViewById(R.id.watch_view_stub);  
   stub.setOnLayoutInflatedListener(new WatchViewStub.OnLayoutInflatedListener() {  
     @Override  
     public void onLayoutInflated(WatchViewStub stub) {  
       mTextView = (TextView) stub.findViewById(R.id.text);  
     }  
   });  
 }  

 After Android Wear API 23 - layout-round (3 files)

1. layout-notround/activity_main.xml - layout for square watches

2. layout-round/activity_main.xml - layout for round watches

3. MainAcitivity.java pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 protected void onCreate(Bundle savedInstanceState) {  
     super.onCreate(savedInstanceState);  
     setContentView(R.layout.activity_main);  
     mTextView = (TextView) findViewById(R.id.text);    
 }  

That said, since WatchViewStub is part of the Android Wear Support Library, if your current code uses it, it is not a breaking change and you can refactor your code at your convenience. In addition to the -round identifier, developers also use the -notround idenifier to separate resources. So why would you want to use it in place of the default layout? It’s a matter of style. If you have a mixture of layouts, you might consider organising layouts in this way:

  • layout/ - Layouts which works for both circular and square watches
  • layout-round/ and layout-notround/ - Screen shape specific layouts

An even better way to develop for round - values-round/dimens.xml

Maintaining multiple layout files is potentially painful. Each time you add a screen element, you need to go to all the layout files and add this. With mobile devices, you will usually only do this to specify different layouts for phones and tablets and rarely for different phone resolutions. For watches, unless your screen layout is significantly different between round and square (which is rare based on the applications I have seen thus far), you should consider using different dimens.xml instead.

As I experimented with the -round identifier, I found that the easiest way to build for round and square watches is actually by specifying values/dimens.xml and values-round/dimens.xml. By specifying different padding settings, I am able to create the following layout with the same layout.xml file and two dimens files - one for square and one for round. The values used suits this layout, you should experiment with different values to see what works best:

values-round/dimens.xml values/dimens.xml pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 <dimen name="header_start_padding">36dp</dimen>  
 <dimen name="header_end_padding">22dp</dimen>  
 <dimen name="list_start_padding">36dp</dimen>  
 <dimen name="list_end_padding">22dp</dimen>  
pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 <dimen name="header_start_padding">16dp</dimen>  
 <dimen name="header_end_padding">16dp</dimen>  
 <dimen name="list_start_padding">10dp</dimen>  
 <dimen name="list_end_padding">10dp</dimen>  

Before API 23, to do the same would have involved a significant amount of boilerplate code manually specifying the different dimensions for all elements on the screen. With the -round identifier, this is now easy to do in API 23 and is my favourite way to build round / square layouts.

Don’t forget the chin!

Some watches have an inset (also know as a “chin”) in an otherwise circular screen. So how should you can you build a beautiful layout while keeping your code elegant? Consider this design:

pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }

activity_main.xml

 <FrameLayout  
   ...>  
   <android.support.wearable.view.CircledImageView  
     android:id="@+id/androidbtn"  
     android:src="@drawable/ic_android"  
     .../>  
   <ImageButton  
     android:id="@+id/lovebtn"  
     android:src="@drawable/ic_favourite"  
     android:paddingTop="5dp"  
     android:paddingBottom="5dp"  
     android:layout_gravity="bottom"  
     .../>  
 </FrameLayout>  

If we are to do nothing, the heart shape button will disappear into the chin. Luckily, there’s an easy way to fix this with fitsSystemWindows:

pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 <ImageButton  
     android:id="@+id/lovebtn"  
     android:src="@drawable/ic_favourite"  
     android:paddingTop="5dp"  
     android:paddingBottom="5dp"  
    android:fitsSystemWindows="true"  
     .../>  

For the eagle-eyed (middle image of the screen shown below under “fitsSystemWindows=”true””), you might noticed that the top and bottom padding that we have put in is lost. This is one of the main side effect of using fitsSystemWindows. This is because fitsSystemWindows works by overriding the padding to make it fits the system window. So how do we fix this? We can replace padding with InsetDrawables:

inset_favourite.xml

pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 <inset  
   xmlns:android="http://schemas.android.com/apk/res/android"  
   android:drawable="@drawable/ic_favourite"
   android:insetTop="5dp"  
   android:insetBottom="5dp"
/>  

activity_main.xml

pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 <ImageButton  
     android:id="@+id/lovebtn"  
     android:src="@drawable/inset_favourite"  
     android:paddingTop="5dp"  
     android:paddingBottom="5dp"  
     android:fitsSystemWindows="true"  
     .../>  

Although the padding setting in the layout will be ignored, the code is tidier if we remove this redundant code.

Do nothing fitsSystemWindows=”true” fitsSystemWindows=”true”
and use InsetDrawable

If you require more control than what is possible declaratively using xml, you can also programmatically adjust your layout. To obtain the size of the chin you should attach a View.OnApplyWindowInsetsListener to the outermost view of your layout. Also don’t forget to call v.onApplyWindowInsets(insets). Otherwise, the new listener will consume the inset and inner elements which react to insets may not react.

How to obtain the screen chin size programmatically

MainActivity.java

pre.CICodeFormatter{ font-family:arial; font-size:12px; border:1px dashed #CCCCCC; width:99%; height:auto; overflow:auto; background:#f0f0f0; line-height:20px; padding:0px; color:#000000; text-align:left; } pre.CICodeFormatter code{ color:#000000; word-wrap:normal; }
 private int mChinSize;  
 protected void onCreate(Bundle savedInstanceState) {  
     super.onCreate(savedInstanceState);  
     setContentView(R.layout.activity_main);  
     // find the outermost element  
     final View container = findViewById(R.id.outer_container);  
     // attach a View.OnApplyWindowInsetsListener  
     container.setOnApplyWindowInsetsListener(new View.OnApplyWindowInsetsListener() {  
         @Override  
         public WindowInsets onApplyWindowInsets(View v, WindowInsets insets) {  
             mChinSize = insets.getSystemWindowInsetBottom();  
             // The following line is important for inner elements which react to insets  
             v.onApplyWindowInsets(insets);

             return insets;  
     }  
   });  
 }  

Last but not least, remember to test your code! Since last year, we have included several device images for Android Wear devices with a chin to make testing easier and faster:

Square peg in a round hole no more!

Android Wear has always been about empowering users to wear what they want. A major part in enabling this is the round screen. With API 23 and the -round resource identifier, it is easier than ever to build for both round and square watches - delightful experiences backed by beautiful code!

Additional Resources

Why would I want to fitsSystemWindows? by Ian Lake - Best practice for using this powerful tool including its limitations. ScreenInfo Utility by Wayne Piekarski - Get useful information for your display including DPI, chin size, etc.

Categories: Programming

Protecting against unintentional regressions to cleartext traffic in your Android apps

Android Developers Blog - Sat, 05/14/2016 - 20:06

Posted by Alex Klyubin, Android Security team

When your app communicates with servers using cleartext network traffic, such as HTTP, the traffic risks being eavesdropped upon and tampered with by third parties. This may leak information about your users and open your app up to injection of unauthorized content or exploits. Ideally, your app should use secure traffic only, such as by using HTTPS instead of HTTP. Such traffic is protected against eavesdropping and tampering.

Many Android apps already use secure traffic only. However, some of them occasionally regress to cleartext traffic by accident. For example, an inadvertent change in one of the server components could make the server provide the app with HTTP URLs instead of HTTPS URLs. The app would then proceed to communicate in cleartext, without any user-visible symptoms. This situation may go unnoticed by the app’s developer and users.

Even if you believe your app is only using secure traffic, make sure to use the new mechanisms provided by Android Marshmallow (Android 6.0) to catch and prevent accidental regressions.

New protection mechanisms

For apps which only use secure traffic, Android 6.0 Marshmallow (API Level 23) introduced two mechanisms to address regressions to cleartext traffic: (1) in production / installed base, block cleartext traffic, and (2) during development / QA, log or crash whenever non-TLS/SSL traffic is encountered. The following sections provide more information about these mechanisms.

Block cleartext traffic in production

To protect the installed base of your app against regressions to cleartext traffic, declare android:usesCleartextTraffic=”false” attribute on the application element in your app’s AndroidManifest.xml. This declares that the app is not supposed to use cleartext network traffic and makes the platform network stacks of Android Marshmallow block cleartext traffic in the app. For example, if your app accidentally attempts to sign in the user via a cleartext HTTP request, the request will be blocked and the user’s identity and password will not leak to the network.

You don’t have to set minSdkVersion or targetSdkVersion of your app to 23 (Android Marshmallow) to use android:usesCleartextTraffic. On older platforms, this attribute is simply ignored and thus has no effect.

Please note that WebView does not yet honor this feature.

And under certain circumstances cleartext traffic may still leave or enter the app. For example, Socket API ignores the cleartext policy because it does not know whether the data it transmits or receives can be classified as cleartext. Android platform HTTP stacks, on the other hand, honor the policy because they know whether traffic is cleartext.

Google AdMob is also built to honor this policy. When your app declares that it does not use cleartext traffic, only HTTPS-only ads should be served to the app.

Third-party network, ad, and analytics libraries are encouraged to add support for this policy. They can query the cleartext traffic policy via the NetworkSecurityPolicy class.

Detect cleartext traffic during development

To spot cleartext traffic during development or QA, StrictMode API lets you modify your app to detect non-TLS/SSL traffic and then either log violations to system log or crash the app (see StrictMode.VmPolicy.Builder.detectCleartextNetwork()). This is a useful tool for identifying which bits of the app are using non-TLS/SSL (and DLTS) traffic. Unlike the android:usesCleartextTraffic attribute, this feature is not meant to be enabled in app builds distributed to users.

Firstly, this feature is supposed to flag secure traffic that is not TLS/SSL. More importantly, TLS/SSL traffic via HTTP proxy also may be flagged. This is an issue because as a developer, you have no control over whether a particular user of your app may have configured their Android device to use an HTTP proxy. Finally, the implementation of the feature is not future-proof and thus may reject future TLS/SSL protocol versions. Thus, this feature is intended to be used only during the development and QA phase.

Declare finer-grained cleartext policy in Network Security Config

Android N offers finer-grained control over cleartext traffic policy. As opposed to android:usesCleartextTraffic attribute, which applies to all destinations with which an app communicates, Android N’s Network Security Config lets an app specify cleartext policy for specific destinations. For example, to facilitate a more gradual transition towards a policy that does not allow cleartext traffic, an app can at first block accidental cleartext only for communication with its most important backends and permit cleartext to be used for other destinations.

Next steps

It is a security best practice to only use secure network traffic for communication between your app and its servers. Android Marshmallow enables you to enforce this practice, so give it a try!

As always, we appreciate feedback and welcome suggestions for improving Android. Contact us at security@android.com. HTTPS, Android-Security

Categories: Programming

Android Studio 2.1 supports Android N Developer Preview

Android Developers Blog - Sat, 05/14/2016 - 20:05

Posted by Jamal Eason, Product Manager, Android

With the launch Android N Developer Preview, we wanted to give you an easy and comprehensive way to build, test and validate your apps on the latest release with Android Studio. Built on the speed and feature enhancements of Android Studio 2.0, the stable release of Android Studio 2.1 includes updates to the IDE wizards, build system and Android Emulator so that you can try out new features and APIs of the developer preview including the new Jack compiler and Java 8 language support. In addition to support for the N Developer Preview, Android Studio 2.1 also includes performance improvements to Instant Run which leads to faster edit and deploy build speeds. If you are developing and validating your app with the N Developer Preview or want faster Instant Run speeds, you should download or update on the stable release channel to Android Studio 2.1.

Android Studio 2.1 includes the following new features:

  • N Developer Preview Support: Android Studio 2.1 is the best IDE to test and validate your app with the N Developer Preview. Get the latest versions of the preview SDK, experiment with the new Java 8 support, and gain access to the only official Android Emulator able to run N Developer Preview Emulator System Images to help in your testing.
  • Instant Run: For those of you who enjoyed the fast edit, build and deploy cycle with Android Studio 2.0, Instant Run now can now update incremental changes to your app code significantly faster.

Deeper Dive into the New Features

N Developer Preview

On top of new features and APIs of the N Developer Preview, Android Studio 2.1 release includes support for the new Jack compiler and support for Java 8. With the Jack compiler, lambdas, method references, compile-time type annotations, intersection types and type inference are available on all versions of the Android platform. Default and static methods and repeatable annotations are available on Android N and higher. To use Java 8 language features when developing with the N Developer Preview, you need to use the Jack compiler. The New Project Wizard [File→ New→ Project] generates the correct configurations for projects targeting the N.

Getting started with development is as easy generating a new project or updating a few settings in your existing project. Once you are ready to test, you can create a fresh Android Virtual Device (AVD) and run your app on the N Developer Preview using the new Android Emulator.


N Developer Preview on the new Android Emulator

Instant Run & General Build Performance Improvements

Instant Run and general build speed are now faster with two new features: incremental Java compilation and in-process dex.

In previous versions of Android Studio, a single line of Java code change will cause all the Java sources in the module to be recompiled. Now in Android Studio 2.1, incremental Java compilation is enabled by default to reduce compilation time by compiling only what is needed.

We are also speeding up build times by using in-process dex, which converts class files to dex files within the Gradle daemon process. This avoids the costly processing operation of creating separate dex processes. To use this feature, you will need to increase the amount of memory available to the Gradle daemon to at least 2GB (1 GB is the default). This feature will help speed up both incremental and full builds.

We’d appreciate your feedback as we continue to improve Instant Run and general build performance. We are going to keep working on making build times even faster in coming releases. Click here to learn even more about the build changes.

What's Next

Update

If you are using a previous version of Android Studio, you can check for updates on the Stable channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). If you need a new copy of Android Studio, you can download it here.

Test and Validate Apps with N Developer Preview

After you update to or download Android Studio 2.1 and you want to test and develop your apps with the N Developer Preview, create a fresh Android Virtual Device (AVD) for the new Android emulator, and check out these additional setup instructions.

We appreciate any feedback on things you like, issues or features you would like to see. Connect with us -- the Android Studio development team -- on our Google+ page or on Twitter.

Categories: Programming

Enhancing App Security on Google Play

Android Developers Blog - Sat, 05/14/2016 - 20:02

Posted by Eric Davis, Android Security Team

We’re constantly investing in new tools and services to help developers build secure Android applications. This includes the application sandbox and Security APIs in the platform, Security APIs in Google Play Services, and even open source testing tools. Last year, Google Play also helped developers enhance the security of their applications by looking directly at the code they’ve written and offering suggestions for improvements.

The Google Play App Security Improvement Program is the first of its kind. It has two core components: We provide developers with security tips to help them build more secure apps, and we help developers identify potential security enhancements when uploaded to Google Play. This week, to help educate developers, Kristian Monsen, one of our engineers, gave a presentation about security best practices at the Samsung Developer Conference. And in 2015, we worked with developers to improve the security of over 100,000 apps through the program.

How it works

Before any app is accepted into Google Play, it is scanned for safety and security, including potential security issues. We also continuously re-scan the over one million apps in Google Play for additional threats.

If your app is flagged for a potential security issue, you will be notified immediately to help you quickly address the issue and help keep your users safe. We’ll deliver alerts to you using both email and the Google Play Developer Console, with links to a support page with details about how to improve the app.


Typically, these notifications will include a timeline for delivering the improvement to users as quickly as possible. Applications may be required to make security improvements before any other app updates can be be published.

You can confirm that you’ve fully addressed the issue by uploading the new version of your app to the Google Play Developer Console. Be sure to increment the version number of the fixed app. After a few hours, check the Developer Console for the security alert; if it’s no longer there, you’re all set!

The success of this program rests on our partnership with you—the developers of apps on Google Play—and the security community. We’re all responsible for providing safe, secure apps to our users. For feedback or questions, please reach out to us through the Google Play Developer Help Center. To report potential security issues in apps, please reach out to us at security+asi@android.com.

Categories: Programming

Get the guide to News app success on Google Play and see how Nabd engages readers with Material Design

Android Developers Blog - Sat, 05/14/2016 - 19:28

Posted by Tamzin Taylor - Strategic Partner Lead, Google Play

Today we’re releasing The News Publisher Playbook, where you will learn best practices for developing a successful news mobile strategy on Android. This is a new companion guide to our business playbook for developers, The Secrets to App Success on Google Play, focused on the news apps segment.

The guide includes tips and useful resources to help you optimize your news content on mobile, identifying the best distribution channels to reach the right audience, build your brand and maximize your revenue.

You will find tips on mobile website optimization, how to create a Google Play Newsstand edition, and how to improve your native app. You will also get an overview of ways to acquire and engage your readers as well as how to monetize and grow your revenue.

Once you’ve checked out the guide, we’d love to hear your feedback, so we can continue to improve our developer resources. Please let us know what you think.

Android Developer Story: Nabd improves reader engagement with Material Design

Founded in 2012, Nabd is a personalised Arabic news aggregator app based in Kuwait, reaching over 10 million people, of which, 60% use Android devices. Watch this Android Developer Story to hear Abdur-Rahman El-Sayed, Co-founder and CEO, and Abdullah El-Sayed, Co-founder and VP of Engineering, explain how adopting Material Design increased user engagement and improved ratings.


Get the News Publisher Playbook to help you find success on Google Play.


Categories: Programming

Designing for Multi-Window

Android Developers Blog - Sat, 05/14/2016 - 19:11

Posted by Ian Lake, Developer Advocate

As a developer, there’s a wide range of features added in Android N to take advantage of, but when it comes to designing and building your UI, having strong multi-window support should be at the forefront.

The primary mode that users will be interacting with multi-window is through split-screen mode, which is available on both handheld devices and larger tablets. In this mode, two apps split the available screen space and the user can drag the divider between the two split screens to resize the apps. As you might imagine, this mode offers some unique design challenges beyond what was needed previously.

An even more responsive UI

The lessons learned from previous versions of Android, the mobile web, and desktop environments still apply to Android N. Designing a responsive UI is still an important first step towards an amazing multi-window experience.

A responsive UI is one that adapts to the size provided, picking the best representation of the content and the appropriate navigation patterns to make a great user experience on any device. Check out the Building a Responsive UI blog post for details on how to design and build an effective responsive UI.

Adapting your layout

As you’re designing layouts for the largest and smallest screens and everything in between, it is important to make resizing a smooth and seamless transition as mentioned in the split screen layout guidelines. If you already have a similar layout between mobile and tablet, you’ll find much of your work taken care of for you.

However, if your mobile and tablet layouts are vastly different and there’s no way to smoothly transition between the two, you should not transition between them when resizing. Instead, focus on making your tablet UI scale down using the same responsive UI patterns. This ensures that users do not have to relearn their UI when resizing your app.

Note that the minimalHeight and minimalWidth layout attributes allow you to set a minimum size you want reported to your Activity, but they do not mean the user cannot resize your activity smaller - it actually means that your activity will be cropped to the size the user requests, potentially forcing elements of your UI off the screen. Strive to support down to the minimum size of 220x220dp.

Design configurations to consider

While many of the sizes and aspect ratios possible in multi-window are similar to existing devices (1/3rd of a landscape tablet is similar to existing mobile devices in screen size), there are a few configurations that are much more common when considering multi-window.

The first is a 16x9 layout on mobile devices in portrait. In this case, the vertical space is extremely limited. If you have a number of fixed elements stacked on top of one another (a toolbar, scrolling content, and a bottom navigation bar), you might find there’s not actually any room for the scrolling content - the most important part!

The second case to consider is the 34.15% layout on tablets. The very wide aspect ratio in device portrait or very tall aspect ratio in device landscape orientation are more extreme than what is found on existing devices. Consider using your mobile layouts as a starting point for this configuration.

Patterns to avoid

When it comes to multi-window, there are a few patterns you want to avoid entirely.

The first is UI interactions that rely on swiping from the edge of the screen. This has already been somewhat of an issue when it comes to the on screen navigation bar prominent on many devices (such as Nexus devices), but is even more so in split-screen mode. Since there is (purposefully) no way to determine if your activity is on the top or bottom or the left or the right, don’t make edge swipes the only way to access functionality in your app. That doesn’t mean you have to avoid them entirely - just make sure there is an alternative. A good example of this is the temporary navigation drawer - an edge swipe opens the drawer, but it is also accessible by pressing the hamburger icon in the toolbar.

The second is disabling multi-window entirely. While there are certainly cases where this makes sense (i.e., it is fundamentally an immersive experience such as a game), there are also cases where your activity and any Activities launched from that Activity are forced to support multi-window. As mentioned in the Preparing for Multi-Window blog post, when you support external apps launching your activity, your activity inherits the multi-window properties of the calling Activity.

Designing for Multi-Window is designing for every device

Building a responsive UI that reacts to the space available is critical to a great multi-window experience, but it is an exercise that can benefit all of your users across the wide variety of Android devices.

So use this as an opportunity to #BuildBetterApps

Follow the Android Development Patterns Collection for more!

Categories: Programming

Introducing the second class of Launchpad Accelerator

Android Developers Blog - Sat, 05/14/2016 - 19:06

Originally posted on Google Developers blog

Roy Glasberg, Global Lead, Launchpad Program & Accelerator

This week Launchpad Accelerator announces its second class, which includes 24 promising startups from around the world. While the number of accelerators is at an all-time high, we take a different approach with Launchpad Accelerator, a program that exclusively works with late-stage tech startups in emerging markets -- Brazil, Indonesia, India and Mexico.

See what it’s like to participate in the Accelerator.


“We provide comprehensive mentorship that delivers results,” says Jacob Greenshpan, one of Launchpad’s lead mentors. “We start by running a ‘patient diagnostic’ to determine each startup’s critical challenges, and then deploy precise mentorship, actionable solutions, and Google resources that enables the app to scale.”

Class 2 kicks off June 13. The startups will descend on Google HQ for an intensive 2 week bootcamp. Under the tutelage of Google product teams and mentors from the global Launchpad network, they will receive intensive, targeted mentoring, equity-free funding, and more benefits during the 6-month program.

Here’s the full list of startups (by country):

Brazil BankFacil Emprego Ligado AppProva GetNinjas Edools Love Mondays Indonesia HijUp Talenta Jarvis Store Ruangguru IDNtimes Codapay India Taskbob Programming Hub ShareChat RedCarpet PlaySimple Games MagicPin Mexico Aliada SaferTaxi Conekta Konfio Kichink Miroculus

Google’s “Scalerator” Drives Results for Alumni

What advice do Class 1 alumni give to the new intake? “Come to the accelerator with an open mind. You will be shocked to find how many things are going wrong in your app. Thankfully the mentors will help you implement better solutions,” says Vinicius Heimbeck, Founder of Brazilian mobile game developer UpBeat Games.

UpBeat Games had more than 1,000% increase in daily app installations in Asia during the period of a feature, as well as a 200% overall increase in active users after following a long list of improvements Accelerator mentors suggested. “We made optimizations that led us to be featured in Google Play, which changed everything for us.”

See Upbeat Games at the Accelerator in this video.

“Believe you can build a world class product. The mentors will push you to bet on yourself,” says Amarendra Sahu, Nestaway Co-founder and Class 1 alumni. NestAway just closed a $30M Series C, one of the largest investment rounds in India this year.

“Your biggest enemy is not failure; it is the temptation to be ordinary. But the mentors will push you to build an extraordinary product and scale an extraordinary startup," says eFishery Co-founder and CEO Gibran Chuzaefah Amsi El Farizy, who was announced as one of the top 27 leaders in Indonesia’s startup ecosystem, after participating in the Accelerator program.

Categories: Programming

Get ready for Google I/O 2016

Google Code Blog - Fri, 05/13/2016 - 21:53

Posted by Mike Pegg, Head of Developer Marketing

Google I/O is almost here! We’ll kick-off live from the Shoreline Amphitheatre in Mountain View at 10AM PDT next Wednesday, May 18th. This year’s festival will focus on key themes that matter to you: Develop, to build high quality apps; Grow & Earn, to increase user engagement and create successful businesses; and What’s Next, a look at new platforms for future growth.

While we’re putting the finishing touches on the keynote, sessions, and code labs, we wanted to provide you with some tips to get ready to experience I/O, either in-person or offsite.

Navigate the conference with the Web & Mobile apps

To get the most out of Google I/O, make sure to install the Android or iOS app and add the web app to your mobile homescreen. The apps will help you plan your schedule (even while offline!), view the venue map, and keep up with the latest I/O details.



Attending in person?

Badge pick-up starts on Tuesday, May 17th, between 7AM - 7PM at the Shoreline Amphitheatre. Keynote seating will be pre-assigned on a first come, first served basis during badge pick-up so plan to come by early on! Remember to bring your ID, the QR code that will be emailed to you before the conference, proof of academic eligibility if you registered for an Academic badge, and your best look for the badge photo! Find the full badge pick-up schedule here.

After the keynote ends, in addition to attending technical sessions, you’ll have the opportunity to talk directly with Google engineers throughout the Sandbox space which will feature multiple product demos and activations; during Code Labs where you can complete self-paced tutorials; and at Office Hours where you can get specific questions answered by Google specialists.

Don’t forget to bring your (comfortable) party shoes! On Day 1, we’ll have an After Hours Concert from 7-10PM that will include dinner, drinks, and feature some exciting musical performances we think you’ll enjoy! On Day 2, we’ll have an After Hours Party from 8-10PM which also includes food, drinks and lots of fun activities. Enjoy the time to explore the venue at dusk - it will look quite different than during the day. We recommend bringing a jacket for the evening festivities as it can get chilly after dark.

Attending remotely?

Whether you’re looking to experience I/O with other devs in your neighborhood, or if you’ll be streaming it live from your couch, here are some ways you can connect with I/O in real-time:

  • I/O Extended: Find an I/O Extended event happening in your community. There’ll be over 450 events taking place around the world organized by Google Developer Groups, Student Ambassadors, and local developers who will be watching the I/O keynote together, participating in hackathons, code labs, and much more.
  • I/O Live: Tune into the live stream throughout the 3 day festival on google.com/io and via the Android and iOS app. If you want to bring the live stream and the #io16 conversation to your audience, you can customize and embed our I/O Live widget on your site or blog.
  • #io16request: Send us your I/O questions on May 18-20 via public english posts on Google+ or Twitter that include the #io16request hashtag. A team of onsite Googlers will do their best to track down an answer in real time for you.
  • I/O in photos: Be sure to check out real time photos from Mountain View on all three days of the event.

We’re looking forward to having you with us for 3 days of I/O fun, soon!

Don’t forget to join the social conversation at #io16!

Categories: Programming

Versnel je team met Scrumban!

Xebia Blog - Fri, 05/13/2016 - 13:01
Herken je dat ook? Teams die meer dan een half jaar aan het scrummen zijn en sprint commitments maar niet halen? Of maar geen stijgende 'velocity' laten zien? Blijven verbeteren zonder een echte verbetering te zien? Scrumban is het toepassen van de Kanban Methode in de context van scrum en geeft deze teams een weg

Metrics: Adding Complexity to Cumulative Flow Diagrams

Waterfall

A waterfall is an example of a complex flow!

The simple cumulative flow diagram (CFD) used in Metrics: Cumulative Flow Diagrams – Basics introduces most of the concepts needed to read and use a CFD. However, software development, regardless of the size of the work or the method used, is more complicated.  CFDs adapt to the true complexity of software development. CFDs allow teams and managers to visualize the flow of work .

An Example of Increased Complexity: 

Context:  In 2011, an application maintenance team built kanban board that included each of the major steps in their software development process. 

1

The team was using a “kanban-y” version of Scrumban with planning and retrospectives every two weeks, but without any requirement to have an empty board (all cards complete) before the end of the two week period.  Releases primarily occurred once a month when a group of features was completed, but could occur as work completed testing for critical items (interim releases were generally problem tickets). 

Scenario One: A standard pace of work is shown in the CFD approximately four weeks after implementing their Scrumban approach. The team established an initial backlog of 137 stories (no additional stories were added during the timeframe, and many lower priority stories had not been groomed) of which 12 were in process and 7 had been completed.  The CFD for this point in time is shown below:

2

At this point, the flow of work shows the backlog items flowing normally through the steps of the process to completion.  For those of you that watch replays of sporting events late at night, you will recognize the first scenario as a ploy to introduce the standard ebb and flow of work before jumping forward to a point in the process where “stuff” happens. 

Scenario Two:  Approximately six weeks into the team’s use of Scrumban, they noticed a bottleneck between assignment (the triage level analysis in this group) and analysis, and more troubling between development tasks and testing. 

3

While the team had set work-in-process limits due to time pressures and a lack of coaching they did not adjust roles when backups started to emerge.  In retrospect, the team found that one of the coders who had been new to the team was really good at coding APIs and that a few of the functions being worked on had no automated testing facilities. This caused stories to begin to pile up waiting to be tested. The problem of stories piling up in the assignment category was a reflection of a lead developer that ignored WIP limits and starting to triage more stories than the analysis step could absorb and work on.  The CFD let the team and management to visually identify evidence of the problems as they began to emerge and find solutions.  The CFD two weeks later showed substantial improvement (below).

5

The team stopped starting new work for a period of time (reflected in the flat backlog) and shifted the technical lead to support code reviews and the testing process (they kept him busy enough that he would not fall prey to the urge to do more triage).

The examples shown here are a reflection of specific points in time.  The team and their leaders were reviewing their CFD on a daily basis during their stand-up meetings. The CFD was easier to use than a classic Kanban board with WIP limits.  The team was distributed across several time zones and two continents.  The team held two separate stand-ups one in the US and one in India.  The team passed an updated CFD to the other location at the end of the day so they could visually recognize progress.  As we have seen in Metrics:  Cumulative Flow Diagrams – Basics, CFDs are useful for showing and monitoring a wide range of metrics.  Each of the metrics (velocity, throughput, cycle time to name a few) a CFD shows will be directly affected by the flow of work between the steps; therefore, adding the complexity of tracking work through the varied steps provides additional transparency and value to a CFD.


Categories: Process Management