How to use “productFlavors” in gradle

Main documentation

How to run specific buildvariant

How to create Java root folder in favor folder

How to override string resource


Fragment lifecycle

Though a Fragment’s lifecycle is tied to its owning activity, it has its own wrinkle on the standard activity lifecycle. It includes basic activity lifecycle methods such as onResume(), but also important are methods related to interactions with the activity and UI generation.
The core series of lifecycle methods that are called to bring a fragment up to resumed state (interacting with the user) are:

  1. onAttach(Activity) called once the fragment is associated with its activity.
  2. onCreate(Bundle) called to do initial creation of the fragment.
  3. onCreateView(LayoutInflater, ViewGroup, Bundle) creates and returns the view hierarchy associated with the fragment.
  4. onActivityCreated(Bundle) tells the fragment that its activity has completed its own Activity.onCreate().
  5. onViewStateRestored(Bundle) tells the fragment that all of the saved state of its view hierarchy has been restored.
  6. onStart() makes the fragment visible to the user (based on its containing activity being started).
  7. onResume() makes the fragment interacting with the user (based on its containing activity being resumed).

As a fragment is no longer being used, it goes through a reverse series of callbacks:

  1. onPause() fragment is no longer interacting with the user either because its activity is being paused or a fragment operation is modifying it in the activity.
  2. onStop() fragment is no longer visible to the user either because its activity is being stopped or a fragment operation is modifying it in the activity.
  3. onDestroyView() allows the fragment to clean up resources associated with its View.
  4. onDestroy() called to do final cleanup of the fragment’s state.
  5. onDetach() called immediately prior to the fragment no longer being associated with its activity.

* Source

How to implement Navigation Drawer with toolbar in Material Design

1. Simpe Github project using ActionBarActivity and v7 support library

2. Excellent explanation about using Material Design in pre-Lollipop

3. Official documentation about How to use Navigation Drawer

What attributes are used in using permission tag and protection level?

<permission android:description="string resource"
            android:icon="drawable resource"
            android:label="string resource"
            android:protectionLevel=["normal" | "dangerous" | "signature" | "signatureOrSystem"] />


Characterizes the potential risk implied in the permission and indicates the procedure the system should follow when determining whether or not to grant the permission to an application requesting it. The value can be set to one of the following strings:
Value Meaning


The default value. A lower-risk permission that gives requesting applications access to isolated application-level features, with minimal risk to other applications, the system, or the user. The system automatically grants this type of permission to a requesting application at installation, without asking for the user’s explicit approval (though the user always has the option to review these permissions before installing).


A higher-risk permission that would give a requesting application access to private user data or control over the device that can negatively impact the user. Because this type of permission introduces potential risk, the system may not automatically grant it to the requesting application. For example, any dangerous permissions requested by an application may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities.


A permission that the system grants only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user’s explicit approval.


A permission that the system grants only to applications that are in the Android system image or that are signed with the same certificate as the application that declared the permission. Please avoid using this option, as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed. The “signatureOrSystem” permission is used for certain special situations where multiple vendors have applications built into a system image and need to share specific features explicitly because they are being built together.



How to use user defined permission in two apps?

Let’s say…

We have 2 apps, App001 and App002 and App001 wants to use the service in App002.

in App001’s AndroidManifest.xml

<uses-permission android:name="com.testpackage.mypermission"/>

in App002’s AndroidManifest.xml



&amp;amp;amp;amp;lt;service android:name=&amp;amp;amp;amp;quot;string&amp;amp;amp;amp;quot;
         android:permission=&amp;amp;amp;amp;quot;string&amp;amp;amp;amp;quot; &amp;amp;amp;amp;gt;
    . . .

The name of a permission that that an entity must have in order to launch the service or bind to it. If a caller of startService(), bindService(), or stopService(), has not been granted this permission, the method will not work and the Intent object will not be delivered to the service.
If this attribute is not set, the permission set by the element’s permission attribute applies to the service. If neither attribute is set, the service is not protected by a permission.



What is the application sandbox in android?

In computer security, a sandbox is a security mechanism for separating running programs.

The Android platform takes advantage of the Linux user-based protection as a means of identifying and isolating application resources. The Android system assigns a unique user ID (UID) to each Android application and runs it as that user in a separate process. This approach is different from other operating systems (including the traditional Linux configuration), where multiple applications run with the same user permissions.

This sets up a kernel-level Application Sandbox. The kernel enforces security between applications and the system at the process level through standard Linux facilities, such as user and group IDs that are assigned to applications. By default, applications cannot interact with each other and applications have limited access to the operating system. If application A tries to do something malicious like read application B’s data or dial the phone without permission (which is a separate application), then the operating system protects against this because application A does not have the appropriate user privileges.