Scaling Android Development: Insights on Team Management, Testing, and Open‑Source Practices

AnDevCon, billed as the world’s largest Android developer conference, hosted a panel in July 2015 where experts from Twitter, Amazon, Cyanogen, Square, Eventbrite, HiQES and Possible Mobile discussed how to build Android applications that scale to millions of users.

The discussion covered team management, testing and testability design, feature and release management, support, open‑source contributions, and optional architectures.

Q: How do you manage teams to support massive feature development? Ty described Twitter Fabric’s growth from 15 to 60 engineers, emphasizing small, independent feature teams that meet weekly. Juan highlighted the importance of automated testing to ensure new code does not break existing functionality.

Q: How do you test new features before releasing to a large audience? Mike explained Amazon’s internal A/B framework that rolls out updates to a small user segment first, allowing the team to identify feature regressions before full rollout. Ty noted that SDK developers prefer stability over frequent feature toggles.

Q: What testing strategies and tools do you use? Howard mentioned CyanogenMod’s reliance on user feedback across hundreds of devices. Square performs thousands of unit tests, asynchronous machine tests, and manual UI tests, using Robotium previously and now Espresso. Jake critiqued Robotium’s limitations with asynchronous operations and praised Espresso’s ability to wait for the main loop to clear.

Fabric is migrating from JUnit to Robolectric for fast local VM tests, creating shadow classes to simulate Android components. They design code for testability by following the single‑responsibility principle and using mocking frameworks. Jake added that wrapping core logic in interfaces enables JUnit testing, while Robolectric allows direct invocation of Android code.

Q: How do you design your program for testability? Juan described using mocking and dependency‑injection frameworks (e.g., Dagger) to decouple code, and investigating Mockito for additional support. Ty explained that in SDK development they avoid heavy DI frameworks to keep the SDK lightweight, instead isolating business logic from activities.

Q: How do you test at the embedded level? Larry explained that kernel‑level drivers and HALs require custom test frameworks, applying modular principles to build testable components in both kernel and user space.

Q: What alternative design approaches have you tried? Jake recounted moving away from over‑complicated fragment management to simpler activity‑based view handling, which reduced crashes and improved maintainability.

Q: Do you use reactive programming or RxJava? Jake shared that Square uses internal helpers and RxAndroid to integrate RxJava’s asynchronous model into Android, despite the overhead of wrapping the API.

Q: How do you adapt Android for a global user base? Mike emphasized localization, right‑to‑left support, handling long German words, and using resource files. He also noted the importance of collaboration between support staff and engineers to generate user stories for new features. Ty, Juan, and Howard added considerations for device fragmentation and low‑resource environments.

Q: How does your organization interact with the open‑source community? Mike described Amazon’s legal‑review process for open‑source contributions. Jake explained Square’s engineer‑driven, lightweight review process that encourages pull‑request contributions. Howard noted Cyanogen’s large community of contributors and the security benefits of open‑source review.

Q: Which open‑source libraries are indispensable? Dave mentioned heavy use of Square’s libraries such as Picasso, Retrofit, and Dagger, while stressing license compliance. Larry highlighted the need for transparency about library usage for customers.

Q: How does analytics help build better apps? Ty discussed A/B testing and Fabric’s analytics for high‑level metrics like user counts and crashes. Jake described using analytics for operational monitoring, tracking feature call frequency to maintain performance as user base grows. Dave added that analytics drive revenue decisions, often employing multiple analytics SDKs.

Q: What resources do you recommend for learning Android? Ty praised the official Android documentation and "The Busy Coder’s Guide to Android Development". Jake noted the scarcity of advanced material for intermediate developers. All agreed that mentorship and pairing junior with senior engineers accelerate learning.

Q: How can designers better understand Android? Dave suggested designers spend time using Android devices, while Juan emphasized providing designers with material design resources and documentation.

The full panel video is available at the linked URL.