Android is an operating system with multitasking, allowing several applications to run at the same time. Developers coming from a different platform may find this a notable change when applying this concept. When starting to develop an Android application, it’s necessary to understand how it works in order to integrate it as well as possible; here we’ll talk about the design, the features, the use, and its development, as explained by Google engineer Dianne Hackborn:

Mobile devices have technical limitations that desktop or web systems don’t have. This article explains the four key principles behind the design of multitasking in Android.

• The choice was made to use memory management based on “temporal locality” (yes, something like a memory cache); in other words, apps aren’t actually closed when the user stops using them, since the tendency is to use a small number of applications throughout the day.

• Mobile devices don’t have the luxury of swap memory space, so they have very restrictive memory limits.

• Switching from one app to another needs to be instantaneous, in under 1 second to launch a new application. Users tend to use only a few apps — for example, they’re watching a video, get a call, and afterward want to keep watching the video. Delays of more than a second can cause users to reject the experience.

• The available API must be sufficient to fulfill Android’s famous philosophy that “all applications are created equal”, both “core” apps and “third-party” ones. This means background music playback, data syncing, GPS navigation, or use of the vibrator are all created without distinction.

The first two requirements are somewhat contradictory. The goal was for the user not to have to worry about closing the app, so it would seem like apps were always running. At the same time, mobile devices have strict limits on memory use, so a system degrades, or even starts failing very quickly, as soon as it needs more RAM. A desktop computer, by contrast, simply slows down its exchange rate with swap space. These considerations were key to Android’s implementation.

The Android Lifecycle

The fundamental mistake when talking about multitasking in Android is not distinguishing between a process and an application. In Android these aren’t tightly bound entities: several applications can share processes, or an application can make use of multiple processes depending on its needs.

The fact that you can see an application’s process “running” doesn’t mean the application is actually doing anything. It may simply be that the operating system has decided this for various reasons, and has decided to keep it around in case it needs it again soon. Likewise, it may leave an application inactive only to return to it a little later, right where it left off.

One of the keys to how Android manages applications is knowing what it does when a process isn’t closed cleanly. When the user exits an application, the process stays in the background, ready to run again if needed (for example, downloading web pages), and can immediately return to the foreground. As long as it doesn’t run out of memory, all processes will remain suspended.
Of course, there’s a limited amount of memory, and the operating system has to decide when to get rid of processes that aren’t needed. This is what’s called “the Android lifecycle“, the set of rules that decide which process should be removed. These rules are based both on the importance of a process, according to the user’s current experience, and on how it’s been used based on past statistics.

Once Android determines it needs to remove a process, it simply kills it. The kernel can immediately reclaim all the resources needed for the new process, without requiring the application to be well written or to respond correctly to an exit command. The operating system takes control so that memory failures don’t occur.

If a user reactivates an application that had been killed, Android has mechanisms to start it up again in the same previous state, in order to preserve the concept that “all apps are running all the time”. This is done by restoring the data visible to the user, the Activities (an activity is the screen we see in the foreground when we run an application). This last state is generated every time the user leaves the app, not when it’s been killed, so the kernel can later freely kill it without depending on the application.

In a way, the process manager can be seen as a form of swap: application processes represent a certain amount of memory in use; when little memory remains, some processes can be killed, and when those processes are needed again, they can be started from their last saved state

Running in the Background

So far, we already know how apps are implicitly used in the background. This is fine for completing downloads, for example, but what happens when we need to explicitly tell the operating system that it should run in the background? Data syncing, GPS, music playback…

The app needs some way to tell Android: ” hey, keep it low-key” . There are two essential mechanisms for background applications, represented by two types of components that can be declared explicitly in its manifest (we’ll talk about that another day): broadcast receivers and services.

BroadcastReceiver

A BroadcastReceiver allows an application to run in the background for a short period of time as a result of something that’s happening. It can be used in many ways to build higher-level facilities: for example, LocationManager can send a message when it detects interesting changes at a given location. Since information about the receiver is part of the application’s manifest (manifest.xml), Android can find and run the application very efficiently, even if it isn’t currently running.
When a “receive” event is handled, the application is given a time quota to finish. If it doesn’t complete within that time, the application is considered to be misbehaving, and its process is moved to suspension.

It’s a way for the app to tell the operating system: “I’ll be done in 10 seconds“.

In short, they’re used when an external stimulus is detected. In any case, they aren’t suitable for long, ongoing transmissions, such as network operations.

Services

A service allows an application to run background operations for longer, in practice. There are actually plenty of other functions that services provide, but here their fundamental purpose is for an application to say “hey, I’m going to be here for a while, I’ll let you know when I’m done” An app controls its service. It says when it runs and when it stops.

Services don’t provide a proper client-server model; their use is optional. When starting an application’s services, Android simply creates an instance of the component within the application’s process to provide its context.
Process management for services is different from BroadcastReceivers, since an unlimited number of services can request to run for an unknown length of time. There may not be enough RAM available to keep the services running, so there’s no guarantee they’ll complete successfully.

If RAM is low, services will be immediately killed, just as background processes are. However, in their case, Android can restart their process later, once more RAM is available.

Informally, you could say services are always acting like a “cry-baby” saying “I don’t want to die”, and in order not to kill it (when RAM is needed) Android wants to see that there’s user interaction — for example, when background music is playing, Android knows the user is aware that process exists thanks to the notification bar where the player can be seen, and therefore it won’t try to kill it.

Smart TVs are a trend. That’s something nobody can deny. Forecasts indicate that by 2017 this sector will end up capturing a good chunk of the mobile app market, with an expected 2.2 million units sold. In countries like Japan, penetration of this type of television already exceeds 60% of households. The price of these TVs is in free fall and the number of apps is growing exponentially. The big internet companies already have theirs: Twitter, Facebook, Skype, Spotify, Google, and many other companies such as digital newspapers, online film platforms, online banking… and new ones are being added every day to the already extensive catalog of applications.

Building on this reality, many companies have already begun making their way down the development path for this platform. They see this device as a chance to reach a mass audience, since the current range of this type of application is still limited, making it easy to grab the pioneer’s share of the market. The family-oriented nature that Smart TVs inspire is also an interesting point to tap into, since it moves away from the individualistic profile of smartphone apps. When we talk about a mobile device such as any smartphone or tablet, we’re talking about a device that’s mostly for individual use, so the nature or orientation apps should have is determined by that premise. In the case of Smart TV apps, this scope expands to reach the whole family, so applications in this sector should tend to become part of everyday life at home. Another point that companies starting out in this sector want to capitalize on is app quality. In most cases, the current applications available to the general public leave a lot to be desired, either failing to meet expectations or simply not working. All of this shows that a huge market niche is opening up, ready to be seized. Any company that is looking, or has looked, to have a presence in the world of mobile, should take the Smart TV path. At Sozpic we are already prepared to guide you along this path, which is why we offer Smart TV app development services on the leading platforms. We can develop synced apps (TV+Mobile) / Second Screen, e-commerce, and Catch-up TV for media companies.

A new world is opening up… Can anyone top that?

We all know the limitation Apple places on distributing an iOS app to a limited group. Apple’s policy is that you either distribute through the App Store, or you can test it with a small group of people for a very limited time. When you want to distribute an app to a limited group of users (usually an organization or company), you use the “iOS developer enterprise program” account.

It’s a perfect solution for distributing in-house apps for companies. Thanks to this program, you avoid Apple’s validation process and the possible rejection due to failing to meet one of the App Store requirements.

To gain access to the Apple enterprise program, it must be a company that applies, and it must also have a D-U-N-S number (an international company ID). It’s essential.

The app cannot be distributed to people outside the organization, as this is one of Apple’s requirements.

Once all the steps to subscribe to this program have been completed, apps can be distributed “freely” via OTA using one of the options Xcode provides, “Save for Enterprise Distribution”. A series of details are requested, and this generates, in addition to the IPA file, a PLIST descriptor file.

It’s well known that Apple exercises tight control over the apps in its App Store. Anything related to usability, user experience, and relevant content is carefully reviewed, and corrected or rejected if it fails to meet a guideline. This blog has already covered Apple’s app acceptance process, and this time we’ll look at another aspect Apple tries to control, with mixed success: the marketing and advertising of apps published on the App Store.

This article will lay out Apple’s guidelines for using its brand correctly. We won’t include all of them since there are many — we’ll just highlight the most notable ones.

Introduction

The introduction itself makes it clear, as if it were article 1 of the constitution:

“Important: Apple’s approval is required. Apple should approve all video, print, or other materials with any visibility before distribution or publication, for both marketing and advertising purposes. Send your initial concept or final version by email as described below. The response will take about seven business days; not receiving a response from Apple within this period does not mean the materials have been approved. You can send Apple materials that are still in development for review, but final versions must be approved by Apple before distribution or publication.

About the Apple and Apple Store badge. You must not use it in the following situations:

• Don’t use the App Store badge in general promotions for your company or for any other products you offer. The badge must be associated only with an app that is available on the App Store.
• Don’t use the badge if the medium it needs to appear on can’t reproduce it clearly and in high resolution.
• Don’t turn the badge into the main message or graphic of the design. It should take a secondary place relative to your main message and your app or company’s own badge.
• Don’t use the iTunes logo.
• Don’t use the Apple logo on its own.
• Don’t animate, rotate, or tilt the App Store badge.
• Don’t modify the badge’s design.
• Don’t refer to iOS. Use the correct product names.
• Don’t use graphics or images from Apple’s or the App Store’s website.
• Don’t use the App Store badge as part of a compatibility message. Include a list with the names of the products compatible with your app.

Product use. You must not use it in the following situations:

About the App Store icon. You must not use it in the following situations

• App Store icon
• Only use the App Store icon when including a group of media icons of the same shape and size.
• Never use the icon in place of the App Store badge in marketing communications, even when the available space is limited.

Conclusion

Apple wants to convey a sense of control, not only over the mobile app business, but also over how its brand is presented in each and every one of them — even when that’s next to impossible. Either way, these serve more as recommendations when designing a marketing campaign for a new mobile app. Mobile marketing is something that will be talked about a lot in the coming months.

Nowadays, nobody doubts the usefulness of Google Analytics in the world of Online Marketing. Website administrators have been able to better understand the profile of the users visiting them, segment, monitor traffic, and even improve their website’s usability. Many professions have emerged around this tool, such as SEO manager and UI engineering. In the offline world, gathering this kind of data costs millions of euros and is almost always based on distant approximations or statistics.

Google Analytics was born in 2005, revolutionizing the world of web statistics. For unknown reasons, Marketing departments in Spain and Latin America took many years to adopt this powerful tool, even though, by then, the web was already an essential element for marketing products and services.

Today, exactly the same thing is happening: the mobile applications are an extremely important element in many companies’ marketing, their commercial potential is almost unlimited, and nothing is done to monitor user interactions or how they handle information. The options offered on mobile are very similar to those offered on the web.

Indeed, Google Analytics for mobile applications has existed since 2011, for both iOS and Android. It’s an extremely powerful tool that Sozpic integrates into applications where understanding the customer, their preferences, and how they interact is essential. Google Analytics for mobile applications shouldn’t be confused with the Google Analytics mobile app, which was released a few months ago and simply lets you check the data obtained from Analytics, whether web or mobile. Nor should it be confused with the statistics offered by Google Play in the developer console, since these only refer to downloaded applications.

New Mobile App Analytics

The new Mobile App Analytics is designed to measure the entire lifecycle of the mobile application (from the moment the user discovers the app until they uninstall it). This allows for the creation of more useful and engaging user experiences through decisions based on data gathered at each stage of the application’s lifecycle:

Below we’ll see the sections that will be available in the new reports, but they will only be available for applications using SDK v2.0.

New and active users: Shows the number of new and active users the app has, as well as the number of people who delete it.

Traffic Sources: Shows visitors coming from Google Play, other parallel app marketplaces, or advertising campaigns like AdMob, with which there’s a close relationship (I’ll write about the new AdMob another day)

Different information about the mobile device: You’ll be able to get data such as the device model they use, the operating system version, the screen resolution they use, and the language it’s set to. As well as how often it’s used. Data that lets you get to know your potential user better.

User behavior: Just like web-oriented Analytics, you can check the new user-to-returning user ratio, as well as how often the application is used and the engagement level of each segmented group. This new visualization is very interesting and useful, since it shows at a glance visitor loyalty and how to interact with the application.

Flow : Shows the screens and paths users take when using applications. There are differences from web Analytics; for example, different colors are used to represent different interactions.

Bugs: You’ll be able to detect bugs and when they occur. This is very useful for developers since it lets them know exactly where the problem is.

App ecommerce : Shows the number of purchases and the revenue generated by purchases in the app. A useful feature that will give a boost to online stores in mobile applications. Unfortunately, although AdMob is integrated for advertisers (meaning they can see the traffic that results from their ads), it still isn’t integrated for publishers (meaning a website that shows ads in its mobile app can’t tell when an ad was clicked).

In summary, this is a major change in what Google Analytics offers. Google is betting heavily on mobile. Steps are being taken toward optimizing the mobile experience. Google has already published its “mobile style guide” anticipating what mobile SEO will become.

Looking at it plainly, Android is a software stack for mobile devices that includes an operating system, middleware, and key applications. The Android SDK provides the tools and APIs needed to start developing applications for the Android platform using the Java programming language.

Memory in Android

As we’ve said more than once, Android is a Linux-based operating system running kernel 2.6.x, simplified to handle most tasks. It uses open native C libraries. All the operating system’s basic operations — I/O, memory management, and so on — are handled by the Linux kernel.

Memory management is fairly standard. Just like Java and .NET, Android uses the runtime and the virtual machine to manage the application’s memory. Unlike either of those two frameworks, the Android runtime also manages process lifetimes. Android keeps the app responsive by stopping and killing processes that get in the way of smooth performance, freeing up resources for higher-priority applications.

Every Android application runs in its own independent process, inside its own instance of Dalvik, handing off all responsibility for memory and process management.

Dalvik and the Android runtime sit on top of a Linux kernel that handles low-level hardware interaction, including drivers and memory management, while the API set provides access to all the low-level services, features, and hardware.

The Dalvik Virtual Machine is a register-based virtual machine that has been optimized to ensure a device can run multiple instances efficiently. It relies on the Linux kernel for low-level memory management.

The Dalvik Virtual Machine

One of the key elements of Android is the Dalvik virtual machine. Instead of using a traditional Java virtual machine (VM), such as Java ME (Java Mobile Edition), Android uses its own custom virtual machine designed to make sure multitasking runs efficiently on a single device.

The Dalvik virtual machine uses the underlying Linux kernel to handle low-level functionality, including security, process scheduling, and memory management.

All access to Android’s hardware and system services is managed through Dalvik as a middle layer. By using a virtual machine to organize application execution, developers get an abstraction layer that means they never have to worry about any particular piece of hardware.

The Dalvik virtual machine launches Dalvik executable processes, a format optimized to keep the memory footprint to a minimum. These .dex executables are created by transforming Java-language classes, compiled using the tools provided in the SDK.

Process priority

The order in which processes reclaim resources is determined by the stored priority of the applications. An application’s priority is equal to the highest priority of its components.

When two processes have been running equally long and both have the same priority, the process that has held a lower priority gets killed first. Process priority is also affected by dependencies between processes: if an application depends on a service or content provider supplied by a second application, the second application will have at least as high a priority as the one it’s supporting.

Every Android application stays running and in memory until the system needs its resources for other applications.

It’s important to make sure a process’s priority matches the work it’s doing. If it doesn’t, the process could be killed while it’s in the middle of something important.

Process types, ordered by priority:

– Active Processes

Active, or foreground, processes are the ones the user is actively interacting with. In general there are only a few of these at any given time, and they’re only killed as a last resort.

Active processes include:

-Activities in an “active” state, meaning they’re in the foreground and responding to user events.

-Activities, Services, or receivers currently running an OnReceive event handler.

-Services currently running OnStart, onCreate, or the OnDestroy event handler.

– Visible Processes

As the name suggests, visible activities are visible, but they’re not in the foreground and don’t respond to user events. This happens when an activity is only partially shown (a screen that isn’t full-size or that’s transparent). In general there are very few visible processes, and they’re only killed in extreme circumstances, to let active processes keep running.

As for services, those that support running active processes are given a noticeably lower priority than active processes themselves, since services don’t interact directly with the user.

– Background Processes.

Background processes cover activities that aren’t visible but are still running. In general this won’t be a large number of processes.

– Empty Processes

Empty processes are kept around to improve the system’s overall performance; Android often retains applications in memory even after they’ve reached the end of their lifecycle. This memory cache is kept in order to improve app startup response times.

How to use memory efficiently

Android manages open applications running in the background. This means it closes apps when the system needs more memory, so there’s no need to fall back on secondary storage. However, most Android users aren’t entirely happy with how this is managed, because it sometimes leaves too many processes running, causing the well-known slowdown compared to iOS (iPhone, iPad…). To fix this, we can always use a task killer