Today we begin a series of interviews with people involved in the sector of the Android OS in a special way, and possibly in the most decisive way possible: as app creators and as professionals capable of getting the most out of the platform. The idea is to see Android From a different perspective than we usually deal with on a daily basis, moving away from the exclusive focus on mobiles, brands or versions, to focus on the perspective of those who build the ecosystem: the app developers and the ROM cooks who modify the base system to fine-tune and improve them.
It has always been said that an operating system lives or dies by its application ecosystem. In the case of Android When it comes to other systems like iPhone OS, this statement makes perfect sense: without quality apps and a vibrant, constantly evolving catalog, no system has a chance of becoming established. Today, it's unthinkable to imagine a mobile operating system without a powerful app store and an active developer community.
Analyzing Android from a developer's perspective also allows for the clear detection of the real strengths and weaknesses of the platform. We'll see what it offers in terms of SDK, APIs, tools, business, monetization, and distribution, but also what problems arise in practice: fragmentation, version management, app store experience, and user relationships.
With this first interview, we're kicking off a series of conversations with developers and technical professionals from different levels, fields, and countries. We're starting with Yeradis Barbosaa developer of applications for Android whom many of you will know from some of his apps. The intention is to publish new interviews regularly and to have people featured in this section. so many voices from the Android ecosystem We'll include as many interviews as possible: junior and senior programmers, architecture experts, mobile product managers, ROM developers, security and performance specialists, and even recruiters who interview Android developers. Starting today, we'll publish a new interview every Wednesday to maintain the project's continuity.
Context: Why interview Android app developers?
Before we delve into the interview with Yeradis, it's worth putting into context why it's so valuable to hear the direct experience of those who work with [the subject] on a daily basis. AndroidThe current mobile market is markedly mobile-firstAnd both digital product companies and startups or traditional corporations are increasingly relying on their apps to compete.
Without a good selection process and without a deep understanding of what it entails modern Android developmentIt's easy to end up with unbalanced teams, difficult-to-maintain applications, and projects delayed by technical problems that could have been foreseen: device fragmentation, poor memory management, architectural errors, security issues, or performance failures under real network conditions.
Today, companies looking to hire Android talent often combine technical interview questions (Kotlin, coroutines, architecture, Jetpack, testing), with practical challenges of mobile system coding and design, as well as behavioral interviews to assess communication, collaboration, and user-centricity. In parallel, developers who want to advance their careers need to know What is really valued in interviews and what the market demands in terms of technical and soft skills.
In this context, interviews like Yeradis's provide a very realistic view: what it's like to program in Android, what Google offers as a project manager, why the open source ecosystem makes a difference, what difficulties it presents Android Market (Google Play) and what it's like to experience all of this from within a community of passionate developers.
1. Who are you and what is your relationship with Android?
My name is Yeradis P. Barbosa Marrero and I'm programmer as a profession and as a hobby. I like to emphasize this because, in the end, a large part of what is learned and built in Android comes from personal curiosity and the desire to experiment beyond working hours.
I am currently related to Android Thanks to my magnificent Magic card, purchased from Vodafone, I've already had a few applications I am developing for this system. That first Android device wasn't just a phone; it was the gateway to a new, open ecosystem full of possibilities that captivated me from day one.
Over time, this connection has grown: from simply using it as a user, I moved on to exploring the SDK, creating small utilities, publishing on the Market, and becoming more involved in the Android communityThat's one of the great advantages of this platform: if you're curious and enjoy programming, the leap from user to developer is within reach of anyone eager to learn.
2. Advantages and disadvantages of Android compared to other systems from a developer's perspective
I'll answer based on my practical experience as a developer, with the humility of knowing that the Android ecosystem is vast and there's always much more to learn. Even so, there are several clear advantages which make Android a very attractive platform for development, and also some real drawbacks that any programmer encounters sooner or later.
2.1. Key advantages of Android for developing applications
The first advantage, almost a worn-out mantra, is that Android is open sourceThis isn't just a label: it means there's enormous access to system source codethat the community can create and maintain Custom ROMs and that thousands of developers can study how everything is built inside.
The benefits of this approach are evident in practice: there is a huge list of Cooked ROMs From the compiled code, these versions are vastly improved, even "boosted," with performance optimizations, additional features, and configurations not found in the stock version. Thanks to this, advanced users have access to a much more polished experience, and developers have an ideal testing ground to experiment with the system.
It is true that for most users this opening simply translates into being able to install Improved ROMsNot everyone sees themselves studying the system's code to modify it. But the mere fact that this possibility exists creates a more vibrant ecosystem, with the capacity for innovation distributed among thousands of people.
The second major advantage is that Google is the main driver and manager of the Android projectFor many, this is already a reason to trust them, but even if you're not particularly a fan of Google, just take a look at the enormous amount of... Public APIs It offers for programmers: Maps, Drive, YouTube, Analytics, Firebase, authentication APIs, push notifications, messaging, and much more.
Almost all of those APIs can be easily integrated into Android applicationsThis allows for the creation of very rich experiences: from apps that rely on location and maps, to complete solutions with cloud synchronization, secure authentication, and detailed usage analytics. In my case, my online life revolves around Google services, and far from seeing this as a problem, I consider it an advantage in terms of productivity and consistency among tools.
Another very important advantage is the flexibility to install applicationsOn Android, you can install apps from the Market (Google Play) as well as from other sources: alternative stores, direct APK downloads, private repositories, etc. For developers, this is invaluable, as it allows them to distribute beta versions, internal builds, or enterprise applications without necessarily going through the public store.
The system that allows you to have multiple applications for the same action without them overriding each other. Think, for example, of browsers: the system browser, Dolphin, Opera Mini… When an app opens a URL, Android displays a list of all available browsers and lets you choose which one you want to use. This intent management And user choices are a differentiating feature: it provides flexibility, respects user preferences, and enables healthy competition between apps that cover the same category.
Another feature I value very much is the technical convergenceThe fact that Android is betting on Java (and today also Kotlin) Using Android as the primary language makes a large portion of the code, design patterns, and libraries reusable in other environments: web projects, desktop applications, or even backend services. The code I write for Android, aside from platform-specific details, can be transferred to other projects, reducing effort and improving the learning curve.
Thanks to this, developers who already master Java can adapt to Android with a very gentle learning curveThere's no need to start from scratch: simply understanding the specific components of Android (Activities, Fragments, Services, etc.), their lifecycle, and how the platform manages resources is enough to start being productive.
2.2. Disadvantages and challenges compared to other mobile systems
Of course, it's not all advantages. Android also presents important challenges compared to other systems like iPhone OS (iOS), Windows Mobile, Symbian, or more recent platforms. One of the most discussed is the fragmentation of versions and devices, a topic we will discuss in more detail later, but which affects you from the very first moment you consider what minimum version you will support.
Furthermore, while the flexibility to install applications from multiple sources is a strength, it also opens the door to security issuesMalicious apps and inconsistent user experiences can occur if users aren't careful about what they install. This forces serious developers to focus particularly on application securityData encryption, use of secure connections (HTTPS, TLS) and best practices to protect user information.
Compared to more closed platforms, Android offers less centralized control over the quality of what is published, which can result in a Saturated marketIt's difficult to navigate and its discovery mechanics could be improved. This is precisely one of my criticisms of it. Android Market in its current form.
Another delicate point is the management of performance and resourcesAndroid offers powerful tools, but it also entails greater responsibility when it comes to managing memory, activity and service lifecycles, multitasking, and background processes. If these aspects aren't carefully managed, it's relatively easy for an app to end up consuming more RAM than it should, draining battery, or malfunctioning on low-end devices.
Finally, although the choice of Java (and today, Kotlin) is correct, the development environment has not always been as smooth as one might expect: the official emulatorFor example, it has historically been slow and cumbersome, which lengthens testing cycles and forces many developers to rely more on physical devices or external device farms.
3. Android Market (Google Play): A critical view from the developer
I think we can agree that the Android Market It needs a major overhaul and a significant improvement, both in the system of app search and discovery...such as in billing management, statistics, and user relations. From the perspective of someone who has, or will have, applications on it—both paid and free—my opinion of the current Market is very critical.
I know this stance may sound radical, but from a developer's point of view, the Market, as it's currently structured, is very limitedThe end-user component is mediocre, and for those of us who publish apps, the Developer Console It leaves much to be desired in terms of information, control, and tools. Many developers turn to alternative marketplaces; personally, I've come to prefer platforms like SlideME.org because of the management and metrics they offer in certain aspects.
3.1. What information does the Android Market actually offer to the developer
Currently, a developer who publishes their applications on the Market can only see very basic information:
- El app name as it is at that moment.
- La published version.
- The amount of scores received and some stars (0 to 5), but without a clear breakdown of the percentage that each level represents.
- El total unique downloads of the application (without separating updates or reinstallations).
- El total active downloads and its percentage of the total.
- If the app is free or paid.
- If the app is published or not.
For many, this may seem sufficient, but from the perspective of a programmer, company, or product manager, this is very poorFundamental data is missing to understand the actual performance of the application, user behavior, and the effectiveness of new versions.
3.2. Critical shortcomings: versions, metrics and user relationship
Some of the most significant limitations I find in the Android Market are:
- There is no name change history neither the app nor in which version each change occurred. This complicates brand analysis and traceability.
- Only the current versionThere is no complete history of published versions nor a structured space to clearly report on the improvements, new features, or bug fixes introduced in each release. Many developers have had to create their own systems to manage changelogs when it would make sense for the Market to offer it by default.
- The ones you can't see scores per version nor filter comments by release or by specific version of the Android systemThis is crucial for debugging errors: a bug that only affects an older version of the system is not the same as one that impacts all versions.
- There is no way to reply directly to comments from the console. If someone leaves a negative comment because they had a problem with an older version, there's no official way to notify them that an update is available to fix the bug. That comment remains there forever, without context. A desirable feature would be the ability to Mark a comment as resolved and notify the user who wrote it, so you can update your rating or see the correction.
This last point is especially painful, because many users only complain in the store comments but don't send a email directly to the developer to explain what went wrong or what they would like to improve. Although it's not their obligation, in a healthy ecosystem, ideally, users who rate an app should take a minute to explain the problem and give the developer the opportunity to... correct itIn other environments, it is more common to see users update their comments when a new version is released and the bug is fixed, but in our Spanish-speaking context this does not always happen.
I also miss more detailed information such as:
- Unique downloads per version (not just the cumulative total).
- Active downloads by version and its corresponding percentage.
- Flexible options of monetization Beyond the simple "free or paid" dichotomy managed solely via Google Checkout, there are users who prefer methods such as PayPal or traditional direct payment options.
- Native support for beta versions, 30-day trials or other test models within the same app listing, without needing to duplicate applications and without losing traceability.
Furthermore, the current system only allows you to mark an app as published or not, but it doesn't offer a simple way to make it visible only to a specific user. specific group of users (internal testers, for example), or to manage development versions and official versions from the same place without resorting to external solutions.
All of this means that, as a developer who has paid a $25 registration fee To publish on the Market, the feeling is that disappointmentThe store's potential is enormous, but the reality is that the control, statistics, and developer tools have fallen short, especially when compared to alternative app market solutions that, while not official, offer a richer and more business-oriented dashboard.
4. Fragmentation in Android: real impact on development
The famous Android fragmentation It's one of the most frequently mentioned topics when discussing this operating system. From a developer's perspective, fragmentation isn't a theory, it's a reality. daily realityI hate it in the best sense of the word, because it forces me to make difficult decisions.
When developing an app, I have to decide for What is the minimum version of Android? I'm going to do it. Depending on which version I choose, many users won't be able to install it. In my case, I usually develop for version 1.5 at a minimum (in the context of the original interview), which already excluded some devices with earlier versions. It's tough having to say, "Sorry, everyone, your version isn't compatible," but sometimes it's the only realistic option.
Versions of the same operating system have always existed, and in a sense, fragmentation is inevitable. The problem arises when the Version differences severely affect applications and force developers to write multiple branches of code or to give up features to maintain compatibility.
Ideally, we would have a solid and homogeneous base of APIs that remain stable over time, and where new versions add layers on top of that foundation without breaking compatibility. Something as simple as allowing the user to install a set of compatibility libraries To access modern features in older versions would alleviate part of the problem. In practice, Google has been introducing solutions such as these. support libraries and Jetpack to mitigate these differences, but the diversity of devices, manufacturers, customization layers and different versions installed in the market keeps fragmentation as a permanent challenge.
For interviewers evaluating Android developers, this topic often comes up in questions such as:
- How would you ensure the compatibility between different devices and Android versions?
- What strategies would you use to manage responsive layouts And resources for different screen sizes and densities?
- What tools or services would you use to test your app across a wide range of devices without having them all physically?
Good candidates often talk about using emulators, device farms, automated testing, adaptive design, continuous review of crash metrics, and an architecture that allows isolating version-specific dependencies.
5. Quality control in the store: strict filters or total freedom?
Apple is frequently accused of being very strict with the App acceptance in the App StoreWhile the Android Market has historically had fewer filters, this raises the question: would it be advisable to implement stricter controls when uploading applications to the Android store?
My personal view is that rigid controls to curb [the/ ... innovation and experimentationbut they are essential authenticity and verification marks in certain types of sensitive apps. For example, it's unacceptable that financial services apps, like banking apps, appear without the user knowing if the bank actually endorses the app or even if it's aware of its existence.
For all those applications that manage money, bank details or particularly sensitive informationYes, more rigorous and visible control by the Market would make sense: a verified app badge, a validation process with the corresponding entity, or a clear security seal that the user can understand at a glance.
The same applies to apps that collect data from well-known services: social networks, messaging, cloud storage… In a context with so many potential threats (malware, phishing, Trojans, etc.), the user needs reliable signals that they are installing a legitimate and secure application.
In interviews with mobile developers that focus more on security, it's common to find questions like:
- What is SSL Pinning And why is this important in apps that communicate with a server?
- How would you protect your application against MITM attacks (Man in the Middle)?
- What policies would you follow to manage sensitive data stored on the device or in transit?
Candidates with a good level of expertise often talk about encryption, proper use of HTTPS and TLS, and good practices in local storage (e.g., using DataStore or encrypted databases), implementation of SSL Pinning if applicable, and use of official APIs from providers such as Google Play Services for authentication and secure backend services.
6. Multitasking and background processes in Android
Lately there has been a lot of talk about multitasking, multitasking and background executionEspecially when other platforms announce changes to how they manage processes (as happened with iPhone OS 4). The key question is whether Android's approach to handling these tasks is effective, and what could be improved.
From my perspective, with limited knowledge of the lower-level inner workings, the way Android handles multitasking already seems reasonably good. The system suspends and resumes activities according to their priority, closes processes when it needs memory, and allows background services to run for specific tasks.
Even so, I miss one clearer process management tool for the user Built-in factory settings. Currently, if a user wants to precisely control what's running in the background, how much memory their apps are consuming, or which processes they could close without breaking anything, they usually resort to third-party tools. It would be desirable for the system itself to provide a well-designed, simple yet powerful interface to understand what's happening under the hood.
Another aspect I would like to see improved is the performance under memory-limited conditionsIt's unacceptable that Android becomes extremely slow and unbearable when it has only 18 MB of free RAM. More optimizations are needed to ensure a smooth experience even under memory-constrained conditions.
In technical interviews about modern Android, in addition to classic multitasking, they usually ask about:
- Use of Work Manager for deferred and reliable tasks even when the app is not in the foreground.
- How to design an app offline-first that syncs when connectivity is restored.
- Good practices to avoid unnecessary wake locks and excessive battery consumption.
Mastering these areas makes the difference between an app that “works” and an app built with sound principles. robustness and efficiency in a real-world context.
7. Evolution of the Android system and maturity of the SDK/NDK
Another interesting point is to analyze the pace of Android evolutionLooking back at the system's beginnings and continuing to the most recent versions, one might think that development has been very rapid. However, my impression is that, in certain aspects, Android hasn't even really started to "run"; in some areas, it's not even "crawling" at the pace it should be.
The changes between versions often seem like something disordered or incompleteIt's unacceptable that we have to wait for version X to incorporate features that should have been present from the first stable iteration. This gives the impression that some decisions were made hastily or without a sufficiently solid long-term vision.
Regarding the development environment, it would undoubtedly improve the Android plugin for Eclipse (in the context of the time of this interview) and, in general, visual tools. Designing entire windows in XML can be very tedious when the visual WYSIWYG options are poor. This limits speed and creativity when building complex interfaces.
Today, with Android Studio and modern tools, the situation has improved significantly, but a well-documented, stable, and powerful SDK and NDK remain essential. Mobile developers are often asked about the following in interviews:
- Experience with the Android SDK for access to sensors, storage, network, push notifications, etc.
- Use of GDR in cases where native performance is needed or to reuse libraries written in C or C++.
- Ability to keep up with the Latest APIs and platform changes, such as new permission restrictions or changes in the behavior of background services.
The key here is not to memorize lists of components, but to demonstrate that you have one architectural vision how all the pieces fit together in a modern and maintainable application.
8. Comparison of Mobile SDKs: Android, Apple OS, Windows Mobile, WebOS
Answering which SDK offers the most features or resources isn't easy, because it depends heavily on the type of project and each developer's experience. For me, the Android SDK It's a great tool. I downloaded it, set up Eclipse, and started programming almost immediately.
The downside is, again, the emuladorwhich I feel like figuratively "torturing": it's extremely slow. This slowness affects the development, testing, and debugging cycles, and forces us to look for alternatives or have more physical devices for testing.
If we compare it to other systems:
- Apple OS (iOS) It offers a very polished SDK, with powerful tools like Xcode, a fast simulator, and a set of highly integrated APIs, but with a more closed philosophy.
- Windows Mobile y WebOS They had moments of maturity in certain areas, but they never achieved the same community and app ecosystem traction as Android or iOS.
- Currently, many developers are also considering options multi platform such as React Native or Flutter, which allow sharing a portion of the code between Android and iOS at the cost of certain compromises.
From the perspective of the technical interview, recruiters typically assess:
- Deep mastery of Android ecosystem (framework, Jetpack, Kotlin, coroutines, Compose).
- General knowledge of differences with iOS and other platforms, to understand limitations and opportunities of each one.
- Ability to reason when to choose native development and when to opt for multi-platform solutions based on project requirements, budget, and deadlines.
9. More innovative APIs and creative possibilities
If you ask me which API I find most innovative or which offers the most possibilities when creating an app, my spontaneous answer is: todasEach well-designed API opens a different door to creativity.
The important thing is not so much the specific API, but the application idea that you have to take advantage of. A location API can be used to create map apps, augmented reality games, logistics systems, or sports tools. A push notification API can bring to life messaging systems, smart reminders, or real-time content experiences.
The same applies to more advanced APIs: on-device machine learning, computer vision, audio, streaming video, etc. The limit is determined by the ability to imagine new uses, for the creativity to combine various APIs and for the technical expertise to bring those ideas to a solid product.
In an interview for an Android position, it is common to ask the candidate about:
- APIs that I have used in real projects and what problems did it solve with them.
- Use case where you have combined several APIs (for example, Location + Notifications + Offline Storage).
- How does she keep up with the New APIs launched by Google and decides which ones to incorporate into their projects.
The best answers demonstrate technical knowledge, but also a mind focused on product and user experiencenot just "using APIs for the sake of using them".
10. Yeradis's future of Android, personal projects, and online presence
I once posted a question that had been on my mind: Will Android dominate the world?And, to be honest, I think it has all the potential to do so. Growth statistics and market share point to a constant increase, and its open philosophy makes companies less resistant to adapting and using it.
For many companies, opting for Android means saving the cost of developing their own system from scratch, while also benefiting from the global community of developers which already exists. This further boosts the platform and creates a virtuous cycle: more devices, more users, more developers, more applications, and greater ecosystem maturity.
As for my personal proyectos and tracking methods:
To follow me—although there isn't always much activity—you can find me on Twitter as @yeradisI also have my own website where I occasionally publish technical and personal content: www.yeradis.com, in addition to my profile linked to Google services.
I currently have two projects published on the Market:
- HelloTXTroid: an application focused on managing states and updates in different services.
- My TV Guide: an app to check all TV programming from your Android device.
If you search for “Yeradis"These apps will appear in the Market, and also on application indexing services like Cyrket and Androlib. Although they aren't the only ones I've started, they are the most active and the ones I've taken furthest in terms of development and support."
I have other projects started but currently on hold, as well as several ideas I want to develop in the medium term. Some of these can be seen on my Google Code profile, which lists public projects and experiments I've shared. My intention is to continue iterating, learning from the community, and, whenever possible, contributing to it. open source and resources that can be useful to other Android developers.
This entire journey, combined with reflections on the market, fragmentation, security, and API design, offers a valuable overview for anyone interested in the Android application developmentWhether you're starting your career, preparing for demanding technical interviews, or improving the quality of the apps you already publish, the combination of a passion for programming, a deep understanding of the platform, and a close connection to the community is probably the strongest formula for continuing to grow this ecosystem.
From here, a huge thank you to Yeradis for participating in this interview and for sharing, without filters, his real-life experience as an Android developer. His perspective helps us better understand not only what it's like to create applications for this system, but also the daily challenges faced by any programmer who wants to build quality mobile products.