Loading...
Home
  • Tech Blogs
  • Videos
  • Conferences
    • Droidcon News
    • Upcoming Conferences
    • Become a Partner
    • Past Events
    • Keep Me Informed
    • Diversity Scholarships
  • Community
    • droidcon Team
    • How to Hold a Droidcon
  • Android Careers
Sign In

Global CSS

 

Binders In Android (Part II): Reference Counting & Death Recipients

 

 
Ashu Tyagi
Senior Android Engineer @Directi
Published: November 30, 2020
Tweet
Share
 
Photo by Crissy Jarvis on Unsplash

 

This is the second part of multi-part series about Binders in Android. It is highly recommended to read Part I (if you haven’t already) otherwise this part probably won’t make much sense.

 

Other articles in this series:

Binders In Android (part 1)

Introduction

proandroiddev.com

 

Introduction

In the first part, we saw that the binder is used for everything that happens across processes in the core platform. They are the driving force behind interaction in the framework and used extensively in the system for security. In this part, we’ll talk about some very important features of binders which make it suitable for hostile environments. But why do we even need to know about death recipients & reference counting mechanism?

Since the very beginning, Android’s central focus has been the ability to multitask. In order to achieve it, Android takes a unique approach by allowing multiple applications to run at the same time. Users usually never explicitly close the applications but instead, leave them running in the background. When memory is low, the Android system kills the low priority apps which are there in the background. This ability to keep processes waiting in the background speeds up app switching later down the line.

Android doesn’t rely on applications being well-written and responsive to polite requests to exit. Rather, it brutally force-kills them without warning, allowing the kernel to immediately reclaim resources associated with the process. This helps prevent serious out of memory situations and gives Android total control over misbehaving apps that are negatively impacting the system. For this reason, there is no guarantee that any user-space code (such as an Activity’s onDestroy() method) will ever be executed when an application’s process goes away.

Considering the limited memory available in mobile environments, this approach seems promising. However, there is still one issue that needs to be addressed: how should the system detect an application’s death so that it can quickly clean up its state? When an application dies, its state will be spread over dozens of system services (the Activity Manager, Window Manager, Power Manager, etc.) and several different processes. These system services need to be notified immediately when an application dies so that they can clean up their state and maintain an accurate snapshot of the system. Here enters the death recipient & reference counting. Now we have good enough reasons to know about these features, so let’s dive into it.

 

Reference Counting

Reference counting guarantees that Binder objects are automatically freed when no one references them and is implemented in the kernel driver. The binder kernel driver does not know anything about binder objects that have been shared with a remote process instead what actually happens is:

  1. Once a new binder object reference is found in a transaction, it is remembered by the binder kernel driver.
  2. Every time that reference is shared with another process, its reference count is incremented.
  3. The reference count is decremented either explicitly or automatically when the process dies.
  4. When a reference is no longer needed its owner is notified that it can be released, and binder removes its mapping.

 

Death Recipient

Binder’s “link-to-death” facility, allows a process to get a callback when another process hosting a binder object goes away. In Android, any process can receive a notification when another process dies by taking the following steps:

  1. First, the process creates a DeathRecipient callback object containing the code to be executed when the death notification arrives.
  2. Next, it obtains a reference to a Binder object that lives in another process and calls its linkToDeath(IBinder.DeathRecipient recipient, int flags), passing the DeathRecipient callback object as the first argument.
  3. Finally, it waits for the process hosting the Binder object to die. When the Binder kernel driver detects that the process hosting the Binder is gone, it will notify the registered DeathRecipient callback object by calling its binderDied() method.

 

Looking at the LocationManagerService source code helps us understand what’s happening under the hood (note that some of the source code has been cleaned up for the sake of brevity):

 

 

Let’s walk through the code step-by-step:

  • When the application requests to get the location, the location manager service’s requestLocationUpdates() method is called. The location manager service registers the location listener for the application, and also links to the death of the location listener’s unique Binder token so that it can get notified if the application process is abruptly killed.
  • When the application requests to remove location updates, the location manager service’s removeUpdates() method is called. The location manager service removes the listener for the application, and also unlinks to the death of the location listener’s unique Binder token (as it no longer cares about getting notified when the application process dies).
  • When the application is abruptly killed before the location listener is explicitly removed, the Binder kernel driver notices that the location listener’s Binder token has been linked to the death of the application process. The Binder kernel driver quickly dispatches a death notification to the registered death recipient’s binderDied() method, which quickly removes the location listener and updates the device’s location service.

 

Wrapping Up

The Binder’s link-to-death & reference counting features are incredibly useful and are used extensively by the framework’s system services. Many other system services depend on these facilities in order to ensure that expensive resources aren’t leaked when an application process is forcefully killed. Some other examples are the VibratorService, PowerManagerService, GpsLocationProvider, and the WifiService.

 

 

 

Tags: Android, Android App Development, AndroidDev, Android Apps, Multitasking

 

View original article at: 


 

Originally published: November 13, 2020

Android News
Compose CameraX on Android
Compose CameraX on Android

By Peng Jiang

Android new UI toolkit Jetpack compose is in beta now, which has all the features you need to build production-ready apps. CameraX is another Jetpack support library, which let you control the camera easier. As compose is still under development, lots of the views are still not available the compose way.

By ProAndroidDev -
Android News
Getting… your BottomSheetScaffold working on Jetpack Compose Beta 03
Getting… your BottomSheetScaffold working on Jetpack Compose Beta 03

By Carlos Mota

It’s Monday, no releases this week, and… there’s a new version of Jetpack Compose — beta 03—available. What a perfect time to just increment 02 to 03 and see what’s new. The API is (almost) final so after updating from alpha to beta there weren’t any big changes to do. However, and remember that’s still in development, there’s always something that I need to update. 

By ProAndroidDev -
Android News
Noisy Code With Kotlin Scopes
Noisy Code With Kotlin Scopes

By Chetan Gupta

Scopes make your code more readable? think again... You are going to encounter these scope functions namely let, run, apply, also, within every Kotlin codebase, along with all the mischievous ways developers exploit their usage from the way they were intended for. Let see how popular opinion on those ends up just as a code noise.

By ProAndroidDev -
Android News
Improving Android DataBinding with Bindables library
Improving Android DataBinding with Bindables library

By Jaewoong Eum

DataBinding is one of the most important factors for MVVM architecture. The basic concept of DataBinding is to link the view and view model via observer patterns, properties, event callbacks, etc. Linking and automating communication between the view via the bound properties or something in the view model has a lot of benefits in the MVVM architecture concept.

By ProAndroidDev -
droidcon News

Tech Showcases,

Developer Resources &

Partners

/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/home-details/EmployerBrandingHeader
EmployerBrandingHeader
https://jobs.droidcon.com/
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/jobs-droidcon/jobs.droidcon.com
jobs.droidcon.com

Latest Android Jobs

http://www.kotlinweekly.net/
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/kotlin-weekly/Kotlin Weekly
Kotlin Weekly

Your weekly dose of Kotlin

https://proandroiddev.com/
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/pad/ProAndroidDev
ProAndroidDev

Android Tech Blogs, Case Studies and Step-by-Step Coding

/detail?content-id=/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Zalando/Zalando
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Zalando/Zalando
Zalando

Meet one of Berlin's top employers

/detail?content-id=/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Academy for App Success/Academy for App Success
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Academy for App Success/Academy for App Success
Academy for App Success

Google Play resources tailored for the global droidcon community

Follow us

Team droidcon

Get in touch with us

Write us an Email

 

 

Quicklinks

> Code of Conduct

> Terms and Conditions

> How to hold a conference

> FAQs

> Imprint

Droidcon is a registered trademark of Mobile Seasons GmbH Copyright © 2020. All rights reserved.

powered by Breakpoint One