Android: Exported and SplashScreen Android: Exported and SplashScreen
A, the android: exported
It sets whether an Activity can be started by a component of another application. “True” means yes, and “false” means no.
If false, the Activity can only be started by components of the same application or by different applications with the same user ID.
Of course, not only activities, but also services and receivers have exported scenarios.
Usually if you use the intent – filter, then exported are not set to “false”, or the Activity is called system throws ActivityNotFoundException anomalies.
On the other hand, if there is no intent-filter, you should not set the Activity exported to true, which may be defined as a security vulnerability during security scans.
On Android 12, with targetSdkVersion 31, you need to note:
ifActivity 、 Service 或 Receiveruseintent-filter, and is not explicitly declaredandroid:exportedThe App will not be installed.
At this point you may choose to go to AndroidManifest and manually modify it one by one, but what if your SDK or third-party library doesn’t support it? Or do you want to launch a package for a different target platform? The following Gradle script will save you some trouble:
/** * Modify Android 12 because of exported build issues */
android.applicationVariants.all { variant ->
variant.outputs.all { output ->
output.processResources.doFirst { pm ->
String manifestPath = output.processResources.manifestFile
def manifestFile = new File(manifestPath)
def xml = new XmlParser(false.true).parse(manifestFile)
def exportedTag = "android:exported"
/ / / designated space
def androidSpace = new groovy.xml.Namespace('http://schemas.android.com/apk/res/android'.'android')
def nodes = xml.application[0].The '*'.findAll {
// Select nodes to be modified. Those that are not specified need to be added
(it.name() == 'activity' || it.name() == 'receiver' || it.name() == 'service') && it.attribute(androidSpace.exported) == null
}
/// Add exported, default is false
nodes.each {
def isMain = false
it.each {
if(it.name() == "intent-filter") {
it.each {
if(it.name() == "action") {
if(it.attributes().get(androidSpace.name) == "android.intent.action.MAIN") {
isMain = true
println("... MAIN FOUND......................")
}
}
}
}
}
it.attributes().put(exportedTag, "${isMain}")
}
PrintWriter pw = new PrintWriter(manifestFile)
pw.write(groovy.xml.XmlUtil.serialize(xml))
pw.close()
}
}
}
Copy the codeGradle: gradle: gradle: gradle: gradle: gradle: gradle: gradle: gradle: gradle: gradle
Retrieve all components that are not exported during the packaging process and dynamically configure them to be exported. It is important to note, there is a special, because the start Activity is need to be the Launcher opens by default, so “android. Intent. Action. The MAIN” need to be exported is set to true.
If necessary, you can specify the default Settings for intent-filter.
Second, the SplashScreen
Android 12 has added a new API for SplashScreen, which includes an action to enter the app at startup, an icon screen to display the app, and a transition effect to display the app itself.
It is roughly composed of the following four parts, which need to be noted:
- Preferably a vector drawable object, of course it can be static or animated.
- 2 is optional, which is the background of the icon.
- As with adaptive ICONS, one third of the foreground is obscured (3).
- 4 is the window background.
The splash screen animation mechanism consists of entering animation and exiting animation.
- The entry animation consists of the system view to the splash screen, which is controlled by the system and not customizable.
- The exit animation consists of an animation run that hides the splash screen. If you want to customize it, you can customize it through SplashScreenView.
More detailed introduced here is not opened, interested can look at the official information: developer.android.com/guide/topic… , here mainly introduces how to adapt and use the problem.
First, no matter what version of TargetSDK you have, SplashScreen will be added to all apps when you run them on Android 12 phones.
If you do nothing, the App Launcher icon becomes the SplashScreen icon, and the color specified in the windowBackground property of the theme becomes the background color of the SplashScreen. This startup effect occurs during cold and hot startup for all applications.
In fact, it doesn’t seem to be a problem.
About how to use SplashScreen migration and can refer to the official document in detail: developer.android.com/guide/topic…
Also check out Jetpack’s new member SplashScreen: creating a new App SplashScreen, which details how to use the official Jetpack library to adapt this effect to lower Target platforms.
What we would normally do is:
- 1, upgrade,
compileSdkVersion 31、targetSdkVersion 31&BuildToolsVersion '31.0.0' - 2. Add dependencies
Implementation "androidx. Core: the core - splashscreen: 1.0.0 - alpha02" - 3, increase
values-v31The directory where the - 4, add
styles.xmlCorresponding topic, for example:
<resources>
<style name="LaunchTheme" parent="Theme.SplashScreen">
<item name="windowSplashScreenBackground">@color/splashScreenBackground</item>
<! --<item name="windowSplashScreenAnimatedIcon">@drawable/splash</item>-->
<item name="windowSplashScreenAnimationDuration">500</item>
<item name="postSplashScreenTheme">@style/AppTheme</item>
</style>
</resources>
Copy the code- 5. Give your start
ActivityAdd this theme and use different themes for different directories to achieve the effect.
PS: I personally don’t like it at all.
Third, other
1. The notification center has changed again
Android 12 has made it possible to fully customize the look and behavior of notifications. Previously, custom notifications could use the entire notification area and provide their own layout and style, but now it behaves differently.
With apps with TargetSDK 31, notifications containing custom content views will no longer use the full notification area; Instead, use system standard templates.
This template ensures that custom notifications look exactly like other notifications in all states, such as notification icon and expansion in the collapse state, and notification icon, application name, and collapse in the expansion state. With the Notification. DecoratedCustomViewStyle behavior are almost identical.
2. Android App Links verification
Android App Links is a special type of DeepLink that allows the Web to open the corresponding App content directly within an Android App without requiring the user to select the App. To use it, perform the following steps:
How to use the accessible: developer.android.com/training/ap…
With the App TargetSDK 31, the system makes some adjustments to the verification method of Android App Links, which will improve the reliability of App Links.
If your App relies on Android App Links validation to open web Links in your App, make sure to use the correct format when adding an Intent filter for Android App Links validation. In particular, make sure these intent-filters contain the BROWSABLE category and support HTTPS schemes.
3. Security and privacy Settings
3.1. General location
With an App with TargetSDK 31, the user can request that the App only access approximate location information.
If the App requests ACCESS_COARSE_LOCATION but does not request ACCESS_FINE_LOCATION then there is no impact.
The App with TargetSDK 31 requests the ACCESS_FINE_LOCATION runtime permission and must also request the ACCESS_COARSE_LOCATION permission. When the App requests both permissions, the system Permissions dialog will provide the user with the following new options:
3.2, SameSite cookies
The SameSite attribute of a Cookie determines whether it can be sent with any request or only with same-site requests.
- There is no
SameSiteThe Cookie of the property is treated asSameSite=Lax. - with
SameSite=NoneCookies must also be specifiedSecureProperties, which means they need a secure context and need to be sent over HTTPS. - Links between the HTTP and HTTPS versions of a site are now considered cross-site requests, so unless cookies are correctly marked as
SameSite=None; SecureOtherwise, cookies will not be sent.
You can manually enable the SameSite behavior on the test device by switching webview-enable-modern-cookie-same-site in WebView devTools.
4. Apply hibernation
Android 12 extends the automatic reset permission behavior introduced in Android 11 (API level 30).
If the App user with TargetSDK 31 does not open it for several months, the system will automatically reset all permissions granted and put the App to sleep.
The more you can consult: developer.android.com/topic/perfo…
Four, the last
Basically, except for Exproted and SplashScreen, other products do not need to be adapted. In fact, SplashScreen, I personally think, will be rejected by the product. After all, The treatment of Material Design in China is really a bit miserable, and we can’t get rid of SplashScreen, so we will have to argue with the product for some time. However, the product and Design generally don’t have Android phones, let alone Android 12, so we will talk about it later