% SPDX-License-Identifier: GPL-3.0-or-later OR CC-BY-SA-4.0
\section{App Components}\label{sec:faq:app-components} %%##$section-title>>

\subsection{What are the application components?}\label{subsec:faq:what-are-app-components} %%##$what-are-app-components-title>>
%%!!what-are-app-components<<
Activities, services, broadcast receivers (or only receivers) and content providers (or only providers) are jointly
called application components. More technically, they all inherit the
\href{https://developer.android.com/reference/android/content/pm/ComponentInfo}{ComponentInfo} class and can be launched
via Intent.
%%!!>>

\subsection{How are the tracker and other components blocked in App Manager? What are its limitations?}\label{subsec:faq:how-components-blocked} %%##$limitations-title>>
%%!!limitations<<
App Manager typically blocks application components (or tracker components) using a method called
\href{https://carteryagemann.com/pages/android-intent-firewall.html}{Intent Firewall (IFW)}, it is superior to
other methods such as \textit{pm} (PackageManager), \href{https://github.com/RikkaApps/Shizuku}{Shizuku} or any other
method that uses the package manager to enable or disable the components. If a component is disabled by the latter
methods, the application itself can detect that the component is being blocked and can re-enable it as it has full
access to its own components. (Many deceptive applications actually do this in order to keep the tracker components
unblocked.) On the other hand, IFW is a true firewall and the application cannot detect if its components are being
blocked. App Manager uses the term \textit{block} rather than \textit{disable} for this reason.

Even IFW has some limitations which are primarily applicable for the system applications:
\begin{itemize}
    \item The application in question is whitelisted by the system i.e.\ the system cannot function properly without
    these applications and may cause random crashes. These applications include but not limited to Android System,
    System UI, Phone Services. They will continue to work even if they are disabled or blocked.

    \item Another system application or system process has activated a specific component of the application in question
    via interprocess communication (IPC). In this case, the component will be activated regardless of blocking status or
    even if the entire application is disabled. If there is such a system application that is not needed, the only way
    to prevent it from running is by getting rid of it.
\end{itemize}
%%!!>>

\subsection{Does app components blocked by other tools retained in App Manager?}\label{subsec:faq:components-blocked-by-others} %%##$other-tools-retained-in-am-title>>
%%!!other-tools-retained-in-am<<
\textbf{No.} But the application components blocked by the system or any other tools are displayed in the
\hyperref[subsec:component-tabs]{component tabs}. These rules can be imported from \hyperref[par:import-existing-rules]{Settings}.
However, it is not possible for App Manager to distinguish the components blocked by the third-party tools and
components blocked by the system. Therefore, the applications listed in the import page should be selected with care.
%%!!>>

\subsection{What happens to the components blocked by App Manager which were previously blocked by other tools?}\label{subsec:faq:components-reblocked-in-am} %%##$also-blocked-by-other-tools-title>>
%%!!also-blocked-by-other-tools<<
\textit{App Manager blocks the components again} if requested. In case of unblocking, they will be reverted to the
default state as specified in the manifest of the application. But if the components were blocked by
\href{https://www.myandroidtools.com}{MyAndroidTools (MAT)} with IFW method, they will not be unblocked by App Manager
as it uses a different format. To fix this issue, the rules have to be imported from \hyperref[par:import-existing-rules]{Settings}
at first, in which case MAT's configurations will be permanently removed.
%%!!>>

\subsection{What is instant component blocking?}\label{subsec:faq:what-is-instant-component-blocking} %%##$what-is-component-blocking-title>>
%%!!what-is-component-blocking<<
When you block a component in the \hyperref[sec:app-details-page]{App Details page}, the blocking is not applied by
default. It is only applied when you apply blocking using the \textit{Apply rules} option in the top-right menu. If you
enable \hyperref[subsubsec:instant-component-blocking]{instant component blocking}, blocking will be applied as soon as you block a component.
If you choose to block tracker components, however, blocking is applied automatically regardless of this setting.
You can also remove blocking for an application by simply clicking on \textit{Remove rules} in the same menu in the \textbf{App Details page}.
Since the default behaviour gives you more control over applications, it is better to keep \textit{instant component blocking} option disabled.
%%!!>>

\subsection{Tracker classes versus tracker components}\label{subsec:tracker-classes-versus-tracker-components} %%##$tracker-classes-versus-tracker-components-title>>
%%!!tracker-classes-versus-tracker-components<<
All application components are classes but not all classes are components. In fact, only a few of the classes are components.
That being said, \hyperref[sec:scanner-page]{scanner page} displays a list of trackers along with the number of classes,
not just the components. In all other pages, trackers and tracker components are used synonymously to denote tracker
components, i.e.\ blocking tracker means blocking tracker components, not tracker classes.

\begin{tip}{Info}
    Tracker classes that are not components cannot be blocked. They can only be removed by editing the application itself.
\end{tip}
%%!!>>
