Какие аргументы принимает метод получения системного сервиса в Android Context?

Что проверяют

Знаете ли вы Context не как «то, что просят в конструкторе», а как точку доступа к системным сервисам. Вопрос про аргумент простой, но по нему видно, заглядывали ли вы внутрь и понимаете ли, почему для одних сервисов годится контекст приложения, а для других нет. Следом спрашивают ровно об этом: какой контекст передавать и что сломается, если взять не тот.

Как отвечать

У метода две перегрузки:

• getSystemService(String name): исторический вариант. Принимает строковую константу из Context (Context.NOTIFICATION_SERVICE, Context.WINDOW_SERVICE, Context.LAYOUT_INFLATER_SERVICE) и возвращает Object, который нужно приводить к типу;
• getSystemService(Class<T> serviceClass): доступен с API 23, типобезопасный, getSystemService(NotificationManager.class). Внутри он всё равно сводится к строке через getSystemServiceName(Class).

В Kotlin удобнее расширение из androidx.core: context.getSystemService<NotificationManager>() либо ContextCompat.getSystemService(context, ClipboardManager::class.java). Оба варианта возвращают nullable-тип, потому что нужного сервиса на конкретном устройстве может не быть.

Главная часть ответа это выбор контекста. Сервисы, связанные с отображением (WindowManager, LayoutInflater, всё, что зависит от темы и метрик экрана), берутся у Activity или другого визуального контекста. Взятые у applicationContext, они отдают метрики не того дисплея, и в многооконном режиме это видно сразу. Остальные (NotificationManager, ConnectivityManager, AlarmManager) спокойно берутся у контекста приложения, и так даже лучше: объект переживает поворот экрана.

Где спотыкаются

Берут LayoutInflater у applicationContext и получают вёрстку без темы: атрибуты, объявленные в теме Activity, не применяются, и экран выглядит иначе, чем в макете.

Не проверяют null. Часть сервисов зависит от аппаратных возможностей, и надёжная проверка это PackageManager.hasSystemFeature плюс безопасное приведение типа.

Кладут полученный сервис в статическое поле вместе с контекстом Activity. Сервис живёт долго, Activity после этого не собирается сборщиком мусора, и получается классическая утечка памяти.