Hello, world!

This post has been republished via RSS; it originally appeared at: Android@Microsoft - Medium.

As we stated in our announcement last month, Microsoft is one of the leading publishers in the Google Play Store, producing many apps that are used by people across the world, from all backgrounds, every day to help them achieve more.
As Microsoft employees, we take advantage of what the community worldwide shares, so we believe is our debt to give back too.

Who are we?

We have a wide range of teams and job roles working on our Android products, all working on interesting and challenging projects. Behind this and future blog posts include Engineers, Designers, Project Managers and Engineering Managers working on Android at Microsoft.

Our goal

We want to give back to the community.
We want to cover specific Android related topics such as how a specific team works, the architecture a particular team follows, the infrastructure behind a specific app, and many others.

To start with, we wanted to first answer some of the questions you have asked us through Medium, Twitter, conferences, and other ways, by sharing some of the things we do internally and as a community.
Of course, many of the answers we provide here won’t go into depth, although they will provide a good enough answer as a high-level response.
We will definitely go into more details and cover more topics in future blog posts.

Microsoft apps and teams

Currently, Microsoft has more than 150 apps published by different teams in the Google Play Store, with around 70 in active development receiving frequent updates.
9 of them have more 100M downloads.
5 of them have more than 500M downloads.
The average rating is 4.2 stars, and on apps that have more than 1M downloads, the average rating goes up to 4.33 stars.

Apps are developed in all Microsoft divisions and across 15 World Wide sites.
The following map shows where our Android teams are located:

As you can see, we have many different locations, in many different countries like USA, Canada, Germany, England, Norway, Czech Republic, Israel, India, and China.

In these locations, we can find teams such as Outlook, LinkedIn, PowerPoint, Microsoft Launcher, Yammer, Word, Skype, SwiftKey, Edge, and many more.

Some of these teams are distributed teams, so they do not operate in just one location. For instance, Outlook has people working on it across the globe based in San Francisco, Redmond, New York, Hyderabad, Bangalore, and Suzhou.
In fact, about Outlook we say “The sun never sleeps on Outlook mobile” ;-)

Other teams have people located in just one location like OneNote in Hyderabad.

However, regardless of the internal structure of a team, they all collaborate and interact with other teams across the world.

This variety of teams, apps, and locations make our teams very heterogeneous.

How do we work?

The way different teams work can vary quite a lot across the company. Every team chooses how they want to work in all aspects, methodologies, processes, technology, etc.

For instance, some teams could work by following Agile methodologies, but others could follow a more incubation-style approach to working as they try to create prototypes to test out.

Programming languages

As mentioned, every team chooses how they work, so they also choose which programming languages they want to use.

Some teams could be using just Java as their main programming language, while others could be already working with Kotlin, or even using C++ for code sharing, etc.

Kotlin is definitely a trend at Microsoft. Many teams have already moved to Kotlin and all new code that they develop is written in Kotlin.
Teams such as Sticky Notes embraced Kotlin even before Google announced its official support 2 years ago.
Others like Microsoft To-do have embraced Kotlin later, writing all new code in Kotlin.

C++ is something very important for many teams as well. Products such as Word, Excel, PowerPoint, amongst others take advantage of code sharing so they can share the same core logic with all different apps and platforms.
If they had to write their logic several times, maintaining it, and keeping parity, the effort would be much larger.

And what about other languages and frameworks?
There are apps that are wholly written in, or have components written in, React Native or Xamarin as well.
For instance, Skype has many parts already written using React Native but also uses Java, as well as C++ for hardware related shared code; while Microsoft News is an app fully written in Xamarin.

So as you see here, we are pretty flexible with what programming language we use. We stay on top of industry trends and take into account the great views and experiences of developers within the Android community, and try to experiment as well, whilst still taking into account our different business needs.

Architecture and testing

You guessed it :-D. Every team is flexible to use the architecture they want to follow.
From architectures that don’t use other frameworks to those that use just a few, to completely RxJava-oriented apps, to apps that follow an unidirectional data flow approach, to apps that make extensive usage of Architecture components or apps that follow Uncle Bob’s clean architecture.
Every app and team has the freedom to choose what they want.

In terms of testing, the same applies. Some teams rely completely on unit testing and UI testing using Espresso, while others can use also Appium and/or Cucumber, etc.
Some teams also have their own custom frameworks they have developed internally to further improve their testing and better their QA process.

We are also early adopters of the new improvements Google makes on Android. App bundles and dynamic features, just to name a couple, are some of the latest Android features that some teams use.
We even submit bugs and talk to Google when we find issues, etc.

Code, build and release management

We are open to using tools that are better for our needs. Whether they are proprietary or FLOSS, the only restriction we have is that it must meet the high bar Microsoft sets when it comes to our privacy and security.
Microsoft values this very highly and thus we have extra measures in place to ensure there is a thorough review process before use.

Regarding how we use our source code and build our projects, some teams use GitHub (yes, even before it was acquired), while other teams use Azure DevOps, which includes everything you need to host and build your software.
Of course, as we’ve said before, it is up to each team to decide what tools they use. For instance, some teams handle their build pipeline using Jenkins, whilst others may use Azure DevOps.

Using a combination of alternatives is pretty common for us.

For internal distribution, we mainly use App Center, which can be used not just for Android but also for apps on platforms such as iOS, Windows, Xamarin.

We also take advantage of App Center for bug reports and analytics, as well as for test cloud devices.

FLOSS

Far behind are the times where FLOSS at Microsoft was something similar to being forbidden. Currently, Microsoft embraces it, and engineers are encouraged to use it whenever it’s needed. No more reinventing the wheel.

Of course, we are talking about a big corporation and the misuse of FLOSS could end up placing the company in a bad position. For this reason, we have a tool which scans the provided source code to verify it is really under the license it says it is. Our internal tools have access to the source repository thus can easily be able to scan it.

We also can ask (depending on the purpose of your business, it can be required) to run an Intellectual Property scan. This will run many tests and cross-references to see if the code has parts of it that are under other different licenses that the ones were explicitly cited in its license document/repository.
This scan, even though it takes time to complete, is really helpful since you can see any legal/license issues (i.e. code that was copied-pasted and under a non-compatible license) that are critical and that were not mentioned anywhere.

Things that basically all our apps have to do

Authentication. MSA and AAD are the main ways to authenticate that we have to implement.
For those not used to Microsoft authentication, MSA refers to Microsoft accounts, like the ones you can create easily such as @outlook.com and @hotmail.com.
AAD in the other hand is oriented to enterprise and school accounts under the Azure Active Directory (AAD).

We have open source libraries that help you to support these authentication methods, so if you are interested and want to use them in your own apps: MSA and AAD.

Many apps also implement multi-account like Outlook, Microsoft To-Do, OneNote, etc. you can log in with both your AAD work account and your personal MSA account. So without having to log out and log in again, you can use in the same app two different accounts with your different work and personal spaces.

Another related auth feature that we also add to our apps is SSO (single sign-on) so when a user logs in, it enables access to any of the different Microsoft apps that have implemented it. In our case as first-party apps, when you sign in using your Microsoft account on apps that have already implemented Microsoft SSO, you can log-in on them without providing your credentials anymore.

The other thing that we usually have to work on is on supporting Intune, which is used to enable app protection policies. For instance, Intune is used on corporate mobile phones to allow wiping the data if for instance the phone was lost and it had sensitive information in it, amongst other actions.
If you are interested, you can have a look at Intune here.

Android@Microsoft

We already have talked about the different locations and teams that we have at Microsoft; we also have talked about how we work and the tools we use, and we even have talked about how we work with FLOSS and typical things that we have to implement in our apps.
We hope the previous answers serve to clear some of the questions you had when thinking about Android at Microsoft.

We also wanted to give you a complete picture of what Android is at Microsoft, so a key player for us is our internal community.

As you have seen, we have so many teams and apps distributed around the world, and in a company with more than 120k employees, it is very difficult to know everyone. Our community started as a response to handle that, to improve the communication between teams and locations, to share knowledge, to get support, and to make connections.

Our community has hundreds of people around the world who work in different teams and who have different roles, from engineering to design, from project management to engineering management, etc.

Communication between teams

The core thing in any community is communication and sharing, and here, there is no difference.

For communication, we use extensively Microsoft Teams that is a real-time communication tool.
For us, Teams is very useful. The integration with our internal people’s graph (showing where they lie in the organisation and their colleagues/reports/managers etc.) is amazing. It’s great to have a way to find and discover people that can help you to solve a problem easily, and having different groups related to your needs and requirements.
For our community, we have a Teams group with many channels where we cover things such as Kotlin, events, build pipeline related issues, open source, testing, architecture, etc.

As a monthly summary, we have a newsletter where we cover the topics and questions that were mentioned in our Teams channels’ group, those that were resolved, and those that still need help, so people can still try to help if a message was missed.
In the newsletter we also share documents and solutions that the teams have worked on, we write reports when important events happen as I/O, and of course, we also share things that happen outside in the worldwide community, like new libraries, new events, etc.

And as a persistent and central place to find everything we share, from papers to tips, from links of the talks we have given to the previous newsletters, announcements, group photos, links to external events organized by month, etc. we have our internal SharePoint community website, that is a nice and easy-to-use place to collaborate.

Face to face

An important thing we have in our community is face to face events.

We have monthly meetups that happen in the US and Europe.
These meetings are very valuable to build the local community, to talk about trends, to get support from your colleagues, etc. We are always looking and talking about expanding wherever there is an Android team located.

Along the year, we also run a couple of global and bigger conferences where we try to get together many more people and teams from around the world, where we have talks and workshops, where we meet each other and make connections, where we share what we do, etc.
We work hard to cover the most interesting topics in our talks from a diverse mix of people, including high profile and inspiring personalities from within Microsoft like Joe Belfiore and Miguel de Icaza.

Since we are also very interested in what happens outside our company, we also have talks from non-Microsoft employees as we had last year with Google and Matt Sullivan from the Flutter team, where they showed us how cool this new UI toolkit is.

We have organized these large events in the US, and China, and we are looking to organize more in different locations. Coming soon: India! We have a large number of colleagues here, but as with the local meetups, wherever we feel there is the need to organize one.

And that’s all for our first blog post. We have covered many topics about who, where, what and how.
We hope that it has been useful to you and that we have answered some of your questions.
See you in future blog posts!

Thanks to Guy, Alfredo, Tehmur, and Antonio for the amazing feedback, suggestions and corrections on this article.

Hello, world! was originally published in Android@Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.