There's really no code snippet for this. I'm building an Android app in Android Studio in Kotlin with a main activity in both default portrait and lanscape modes. I'm using Android Studio auto-generated layout\activity_main.xml and layout-land\activity_main.xml layouts.
PROBLEM: When I rotate screens in the app, all widgets reset state. For example, I have a TextView, tvTitle, with a default hardcoded string, "Hello World". tvTitle normally changed to "News" while using the app in portrait mode. I then switched to landscape mode and tvTitle reverted to it's hardcoded default string, Hello. How can I retain the state of the app through rotations?
You might find the solution to your particular problem after understanding the Android mechanisms for saving the application state.
I suggest that you check out the official guide.
Got it. The simple answer that works for me here is:
class MainActivity : AppCompatActivity() {
private var SavedVar = "Hello"
override fun onSaveInstanceState(outState: Bundle) {
super.onSaveInstanceState(outState)
outState.putString("SavedVar_KEY" ,SavedVar)
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
if(savedInstanceState != null) {
SavedVar = savedInstanceState.getString("SavedVar_KEY")
}
...
...
}
For tests I use Espresso and Barista
I have a test in which I need to open another screen by pressing a button. How can I check if this screen opens? Did the screen I need open?
Can I somehow check the chain of screens? To understand that the screens open in the order I need?
If someone throws links to good tutorials on UI tests in Android, I will be very grateful.
An easy solution would be to just check for an element of the new screen to be shown like this:
onView(withId(R.id.id_of_element_in_your_new_screen)).check(matches(isDisplayed()))
If you really want to check out for the current activity that is shown, you could try something like this:
Gather the current activity via InstrumentationRegistry and check for the activity in stage RESUMED.
fun getTopActivity(): Activity? {
InstrumentationRegistry.getInstrumentation().runOnMainSync {
val resumedActivities = ActivityLifecycleMonitorRegistry.getInstance().getActivitiesInStage(Stage.RESUMED)
if (resumedActivities.iterator().hasNext()) {
resumedActivities.iterator().next()?.let {
activity = it
}
}
}
return activity
}
You could then check this in a test like this:
#Test
fun checkForActivity() {
val currentActivity = getTopActivity()
assertTrue(currentActivity?.javaClass == YourActivityToCheckAgainst::class.java)
}
I personally use intended(hasComponent(YourActivityToCheckAgainst::class.java.name)), which checks if the last intent was done with a desired activity, set as its component.
I also wrote an extensive Android UI testing tutorial using Espresso + Barista libraries.
This is an effect that is difficult to describe.
Our Android app supports two languages, however we don't use the system language but let the user set this in the settings.
Then, before attaching the BaseContext of the Application we set the locale configuration.
// in Application class
override fun attachBaseContext(base: Context) {
super.attachBaseContext(LocaleHelper.onAttach(base))
}
// the LocaleHelper
fun onAttach(context: Context): Context {
return setLocale(context, getPersistedLanguage(context), getPersistedCountry(context))
}
That way the attachBaseContext call gets a context that has the locale set to e.g. "de" instead of "en" - even if the device is in English.
This works great so far and depending on the settings all resources coming from the context are in that language. However, we now added another setting for the night-mode (i.e. giving the user the option to set the "theme" in either "normal" or "dark mode").
For that reason the idea was to set something like this
if (enableDarkMode) {
AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_YES)
} else {
AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_NO)
}
in the onCreate() of the Application (we also tried in the Activity).
However, doing this, suddenly the resources (at least some) are loaded with the device locale. The menu entries are in the device language. However, checking the Locale.getLanguage() gives me the configured language and dynamically called Strings (e.g. context.getString(R.string.xyz)) also show in the correctly configured language.
This leads to the assumption that the menu resources are somewhat (re)loaded (again) but don't respect the set Locale from the JVM.
Does anyone have any idea how to find that bug? What are we missing here? Are the menu resources loaded differently?
I just discovered a hacky solution but in case there is anyone having the same problem this might help a bit:
I added to the activity in the manifest
android:configChanges="uiMode"
telling the Application to "handle ui mode changes myself".
In that case the resources stay "untouched" but I'm not sure what other implications this change might have.
So please let me know if you have any further hints on what's going wrong when letting the system / app handle the night mode changes itself.
Maybe late on this, but that can help other.
I managed to make sure that the dark theme doesn't change the locale language.
For that, I have a fragment which enable thank to a switch the dark theme.
SettingsFragment :
switchPreference.setOnPreferenceChangeListener((preference, isSwitchOn) -> {
if((boolean) isSwitchOn){
AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_YES);
} else {
AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_NO);
}
return true;
});
Then in the parent activity, I just have to override attachBaseContext !
SettingActivity :
#Override
protected void attachBaseContext(Context newBase) {
// Get configuration and resources before onCreate method
Resources resources = newBase.getResources();
Configuration configuration = new Configuration(resources.getConfiguration());
configuration.uiMode = Configuration.UI_MODE_NIGHT_UNDEFINED;
Context context = newBase.createConfigurationContext(configuration);
// Set locale with configuration saved
SharedPreferences sharedPreferences = PreferenceManager.getDefaultSharedPreferences(context);
String langue = sharedPreferences.getString("langage_pref", "fr");
Locale locale = new Locale(langue);
Locale.setDefault(locale);
configuration.setLocale(locale);
resources.updateConfiguration(configuration, resources.getDisplayMetrics());
super.attachBaseContext(newBase);
}
Hope that will help you ! :D
I'm trying to support the Android Q Dark theme for my Android app and I can't figure out how to import different assets based on the theme I'm currently in.
Im using the official DayNight theme for making the dark/light versions and for drawables is very easy to just point to the XML and it will choose the correct value either from values or values-night depending on what is enabled.
I wanted to do something similar where depending on the theme it would load either the asset "priceTag_light.png" or "priceTag_dark.png".
val inputStream = if(darkIsEnabled) {
assets.open("priceTag_dark.png")
} else {
assets.open("priceTag_light.png")
}
Is there a way I get that flag?
Okay finally found the solution I was looking for. As #deepak-s-gavkar points out the parameter that gives us that information is on the Configuration. So, after a small search I found this article that gives this example method that has worked perfectly for what I wanted:
fun isDarkTheme(activity: Activity): Boolean {
return activity.resources.configuration.uiMode and
Configuration.UI_MODE_NIGHT_MASK == Configuration.UI_MODE_NIGHT_YES
}
You first need to do this changes in manifest
<activity
android:name=".MyActivity"
android:configChanges="uiMode" />
then onConfigurationChanged of activity
val currentNightMode = resources.configuration.uiMode and Configuration.UI_MODE_NIGHT_MASK
when (currentNightMode) {
Configuration.UI_MODE_NIGHT_NO -> {} // Night mode is not active, we're using the light theme
Configuration.UI_MODE_NIGHT_YES -> {} // Night mode is active, we're using dark theme
}
Use the following code:
boolean isDarkThemeOn = (getResources().getConfiguration().uiMode & Configuration.UI_MODE_NIGHT_MASK) == Configuration.UI_MODE_NIGHT_YES;
I have a multilingual app with primary language English and secondary language Arabic.
As described in the documentation,
I have added android:supportsRtl="true" in the manifest.
I have changed all xml properties with left and right attributes to start and end respectively.
I have added Arabic language strings in strings-ar (and similarly for other resources).
The above setup works properly. After changing the Locale to ar-AE, Arabic text & resources are correctly displayed in my Activities.
However, every time I navigate to an Activity with a WebView
and/or a WebViewClient, the locale, text and layout direction
abruptly revert to the device default.
Further hints:
This is occurring only on a Nexus 6P with Android 7.0. Everything works properly on Android 6.0.1 and below.
The abrupt shift in locale happens only when I navigate to an Activity that has a WebView and/or a WebViewClient (and I have several). It does not occur on any of the other Activities.
Android 7.0 has multi-locale support, allowing the user to set more than one default locale. So if I set the primary locale to Locale.UK:
Then on navigating to the WebView, the locale changes from ar-AE
to en-GB.
Android 7.0 API changes:
As indicated in the list of API changes, new methods pertaining to locale have been added to the following classes in API 24:
Locale:
Locale.getDefault(...)
Locale.setDefault(...)
Configuration:
getLocales()
setLocales(...)
However, I am building my app with API 23, and am not using any of
these new methods.
Furthermore ...
The problem occurs on the Nexus 6P emulator as well.
To get the default locale, I am using Locale.getDefault().
To set the default locale, I am using the following code:
public static void setLocale(Locale locale){
Locale.setDefault(locale);
Configuration config = new Configuration();
config.setLocale(locale);
Context context = MyApplication.getInstance();
context.getResources().updateConfiguration(config,
context.getResources().getDisplayMetrics());
}
Has anyone encountered this problem before? What is the reason for it, and how do I resolve this?
References:
1. Native RTL support in Android 4.2.
2. Multilingual Support - Language and Locale.
3. Be wary of the default locale.
Ted Hopp's answer managed to solve the problem, but he didn't address the question of why this occurs.
The reason is the changes made to the WebView class and its support package in Android 7.0.
Background:
Android's WebView is built using WebKit. While it was originally a part of AOSP, from KitKat onwards a decision was made to spin off WebView into a separate component called Android System WebView. It is essentially an Android system app that comes pre-installed with Android devices. It is periodically updated, just like other system apps such as Google Play Services and the Play Store app. You can see it in your list of installed system apps:
Android 7.0 changes:
Starting with Android N, the Chrome app will be used to render any/all WebViews in third-party Android apps. In phones that have Android N out-of-the-box, the Android WebView System app is not present at all. In devices that have received an OTA update to Android N, the Android System WebView is disabled:
and
Moreover, multi-locale support has been introduced, with devices having more than one default language:
This has an important consequence for apps that have multiple languages. If your app has WebViews, then those are rendered using the Chrome app. Because Chrome is an Android app in itself, running in its own sandboxed process, it will not be bound to the locale set by your app. Instead, Chrome will revert to the primary device locale. For example, say your app locale is set to ar-AE, while the primary locale of the device is en-US. In this case, the locale of the Activity containing a WebView will change from ar-AE to en-US, and strings and resources from the corresponding locale folders will be displayed. You may see a mish-mash of LTR and RTL strings/resources on those Activitys that have WebViews.
The Solution:
The complete solution to this problem consists of two steps:
STEP 1:
First, reset the default locale manually in every Activity, or at least every Activity that has a WebView.
public static void setLocale(Locale locale){
Context context = MyApplication.getInstance();
Resources resources = context.getResources();
Configuration configuration = resources.getConfiguration();
Locale.setDefault(locale);
configuration.setLocale(locale);
if (Build.VERSION.SDK_INT >= 25) {
context = context.getApplicationContext().createConfigurationContext(configuration);
context = context.createConfigurationContext(configuration);
}
context.getResources().updateConfiguration(configuration,
resources.getDisplayMetrics());
}
Call the above method before calling setContentView(...) in the onCreate() method of all your Activities. The locale parameter should be the default Locale that you wish to set. For example, if you wish to set Arabic/UAE as the default locale, you should pass new Locale("ar", "AE"). Or if you wish to set the default locale (i.e. the Locale that is automatically set by the operating system), you should pass Locale.US.
STEP 2:
Additionally, you need to add the following line of code:
new WebView(this).destroy();
in the onCreate() of your Application class (if you have one), and wherever else the user may be changing the language. This will take care of all kinds of edge cases that may occur on app restart after changing the language (you may have noticed strings in other languages or with the opposite alignment after changing the language on Activities that have WebViews on Android 7.0++).
As an addendum, Chrome custom tabs are now the preferred way of rendering in-app web pages.
References:
1. Android 7.0 - changes for WebView.
2. Understanding WebView and Android security patches.
3. WebView for Android.
4. WebView: From "Powered by Chrome" to straight up Chrome.
5. Nougat WebView.
6. Android 7.0 Nougat.
7. Android N Mysteries, Part 1: Android System WebView is just "Chrome" Now?.
Your code seems to be setting the locale in the configuration for the app itself (MyApplication.getInstance()). However, you need to update the configuration for the activity context before inflating the activity's content view. I've found that modifying the app's context isn't enough (and, as it turns out, isn't even necessary). If I don't update each activity context, then the behavior is inconsistent across activities.
The way I approach this is to subclass AppCompatActivity (or Activity, if not using the compatibility library) and then derive all my activity classes from that subclass. Here's a simplified version of my code:
public class LocaleSensitiveActivity extends AppCompatActivity {
#Override protected void onCreate(Bundle savedInstanceState) {
Locale locale = ... // the locale to use for this activity
fixupLocale(this, locale);
super.onCreate(savedInstanceState);
...
}
static void fixupLocale(Context ctx, Locale newLocale) {
final Resources res = ctx.getResources();
final Configuration config = res.getConfiguration();
final Locale curLocale = getLocale(config);
if (!curLocale.equals(newLocale)) {
Locale.setDefault(newLocale);
final Configuration conf = new Configuration(config);
conf.setLocale(newLocale);
res.updateConfiguration(conf, res.getDisplayMetrics());
}
}
private static Locale getLocale(Configuration config) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
return config.getLocales().get(0);
} else {
//noinspection deprecation
return config.locale;
}
}
}
Then I make sure to call super.onCreate(savedInstanceState) in each subclass's onCreate() method before calling any methods (such as setContentView()) that use the context.
This has an important consequence for apps that have multiple languages. If your app has WebViews, then those are rendered using the Chrome app. Because Chrome is an Android app in itself, running in its own sandboxed process, it will not be bound to the locale set by your app. Instead, Chrome will revert to the primary device locale. For example, say your app locale is set to ar-AE, while the primary locale of the device is en-US. In this case, the locale of the Activity containing a WebView will change from ar-AE to en-US, and strings and resources from the corresponding locale folders will be displayed. You may see a mish-mash of LTR and RTL strings/resources on those Activitys that have WebViews.
The Solution:
The complete solution to this problem consists of two steps:
STEP 1:
First, reset the default locale manually in every Activity, or at least every Activity that has a WebView.
public static void setLocale(Locale locale){
Context context = MyApplication.getInstance();
Resources resources = context.getResources();
Configuration configuration = resources.getConfiguration();
Locale.setDefault(locale);
configuration.setLocale(locale);
if (Build.VERSION.SDK_INT >= 25) {
context = context.getApplicationContext().createConfigurationContext(configuration);
context = context.createConfigurationContext(configuration);
}
context.getResources().updateConfiguration(configuration,
resources.getDisplayMetrics());
}
Call the above method before calling setContentView(...) in the onCreate() method of all your Activities. The locale parameter should be the default Locale that you wish to set. For example, if you wish to set Arabic/UAE as the default locale, you should pass new Locale("ar", "AE"). Or if you wish to set the default locale (i.e. the Locale that is automatically set by the operating system), you should pass Locale.US.
STEP 2:
Additionally, you need to add the following line of code:
new WebView(this).destroy();
in the onCreate() of your Application class (if you have one), and wherever else the user may be changing the language. This will take care of all kinds of edge cases that may occur on app restart after changing the language (you may have noticed strings in other languages or with the opposite alignment after changing the language on Activities that have WebViews on Android 7.0++).
As an addendum, Chrome custom tabs are now the preferred way of rendering in-app web pages.
After reading all answers I found out that there is something missing in each one so here is the solution that worked for me so far. Since the WebView overrides the language configuration of the activity's context and application context, you must make sure each time this happens you call a method that resets those changes back. In my case I wrote following class that my activities which present this problem extend (those showing a WebView):
public class WebViewFixAppCompatActivity extends AppCompatActivity {
private Locale mBackedUpLocale = null;
#Override
protected void onCreate(#Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
mBackedUpLocale = getApplicationContext().getResources().getConfiguration().getLocales().get(0);
}
}
#Override
protected void onStop() {
super.onStop();
fixLocale();
}
#Override
public void onBackPressed() {
fixLocale();
super.onBackPressed();
}
/**
* The locale configuration of the activity context and the global application context gets overridden with the first language the app supports.
*/
public void fixLocale() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
Resources resources = getResources();
final Configuration config = resources.getConfiguration();
if (null != mBackedUpLocale && !config.getLocales().get(0).equals(mBackedUpLocale)) {
Locale.setDefault(mBackedUpLocale);
final Configuration newConfig = new Configuration(config);
newConfig.setLocale(new Locale(mBackedUpLocale.getLanguage(), mBackedUpLocale.getCountry()));
resources.updateConfiguration(newConfig, null);
}
// Also this must be overridden, otherwise for example when opening a dialog the title could have one language and the content other, because
// different contexts are used to get the resources.
Resources appResources = getApplicationContext().getResources();
final Configuration appConfig = appResources.getConfiguration();
if (null != mBackedUpLocale && !appConfig.getLocales().get(0).equals(mBackedUpLocale)) {
Locale.setDefault(mBackedUpLocale);
final Configuration newConfig = new Configuration(appConfig);
newConfig.setLocale(new Locale(mBackedUpLocale.getLanguage(), mBackedUpLocale.getCountry()));
appResources.updateConfiguration(newConfig, null);
}
}
}
}
The idea posted by #Tobliug to save the initial configuration before the WebView overrides it worked for me, in my particular case I found this to be more easy to implement than other solutions posted.
Important is that the fix method gets called after exiting the WebView, e.g. when pressing back and in onStop.
If the webView is shown in a dialog you must take care the fix method is called after dismissing the dialog, mostly in onResume and/or onCreate. And if the webView is directly loaded in onCreate of the Activity and not afterwards in a new fragment the fix must also be called directly after setContentView before the activity's title is set, etc. If the WebView is loaded inside a fragment in the activity, call the activity in onViewCreated of the fragment and the activity should call the fix method.
Not all activities need to extend the class above as noted in an aswer, that's an overkill and not necessary.
This issue also does not get solved replacing the WebView by Google Chrome Tabs or opening an external browser.
If you really need your ressources configuratoin to have the whole list of languages set and not only one, then you would need to merge this solution with the one at https://gist.github.com/amake/0ac7724681ac1c178c6f95a5b09f03ce
In my case it was not necessary.
I also did not find necessary to call new WebView(this).destroy(); as noted in an answer here.
Same issue here. I have a dirty, but simple, solution.
Because I observe that the locale is still good in the Activity.onCreate(...) function and no more valid in the Activity.onPostCreate(...) function, I just save the Locale and force it at the end of the onPostCreate(...) function.
Here we go :
private Locale backedUpLocale = null;
#Override
protected void onCreate(final Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
backedUpLocale = getApplicationContext().getResources().getConfiguration().locale;
}
#Override
protected void onPostCreate(#Nullable Bundle savedInstanceState) {
super.onPostCreate(savedInstanceState);
changeLocale(backedUpLocale);
}
Bonus - the change locale function :
public void changeLocale(final Locale locale) {
final Configuration config = res.getConfiguration();
if(null != locale && !config.locale.equals(locale)) {
Locale.setDefault(locale);
final Configuration newConfig = new Configuration(config);
if(PlatformVersion.isAtLeastJellyBeanMR1()) {
newConfig.setLocale(new Locale(locale.getLanguage()));
} else {
newConfig.locale = new Locale(locale.getLanguage());
}
res.updateConfiguration(newConfig, null);
}
}
Hopes it will help.
I want to add one more use-case here:
When pressing back from webview activity(i.e. Showing payment screen and user press back button), onCreate() of previous activity does not execute, So that language got reset again. To keep it bug free, We must reset app locale in onResume() of base Activity.
private static void updateResources(Context context, String language) {
Locale locale = new Locale(language);
Locale.setDefault(locale);
Configuration config = new Configuration();
config.setLocale(locale);
config.setLayoutDirection(locale);
context.getResources().updateConfiguration(config,
context.getResources().getDisplayMetrics());
}
Call above method in onResume() of base activity or atleast in webview activity.
Edit:
If you are dealing with Fragments, make sure this method called when user exit from webview.
I have noticed that this happens only the first time you use a web view in the app , but it will not happen after that (i.e if the language is changed from inside the app and you opened a web view -again- or another webview ,then this time the webview will not change back the language as it did in the first time.
so based on that, a simple solution that I have done is I have added a webview with visibility gone to my very first activity in the app(or the host activity if you use single activity app with fragments) then I apply my locale in that activity's onCreate method after the call to setContentView.So in my activity.xml I will have :
<WebView
android:id="#+id/webview"
android:visibility="gone"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent" />
and in my activity :
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)//at this moment and because there is the webview in the xml, the language will be reverted to the device's language
updateLocal(this ,"en")//this reset it back to whatever language you want to use(from shared preferences for example )
}
and updateLocal having code like following :
fun updateLocale(
c: Context,
languageToSwitchTo: String
): Context {
val locale = Locale(languageToSwitchTo)
Locale.setDefault(locale)
var context = c
val resources = context.resources
val configuration: Configuration = resources.configuration
configuration.setLayoutDirection(locale)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
val localeList = LocaleList(locale)
LocaleList.setDefault(localeList)
configuration.setLocales(localeList)
} else {
configuration.locale = locale
}
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N_MR1) {
context = context.createConfigurationContext(configuration)
}
resources.updateConfiguration(configuration, resources.displayMetrics)
return context
}
In Android N, when you do new WebView(), it will add /system/app/WebViewGoogle/WebViewGoogle.apk to resource path. And if it was not added to the path already, it will cause Resource recreate (only the first time you use WebView in the app).
So if you want to solve the problem, just do new WebView(applicationContext) in Application#OnCreate() before you change the Locale.
If you know Chinese, you can read this blog.
None of the answers above helped me, I managed to reset app locale again inside onStop() method of the activity containing the Webview
If you are using the WebView only to display rich text (Text with some paragraphs or bold and italic text in different font sizes), then you can use TextView and Html.fromHtml() instead. TextViews have no issue with locale settings ;-)
Just Change Parameter For SEt Local Method From Passing BaseContext To "this" Or Exact activity Specially On android 7.0 and older
I'm facing the same issue in the fragment.
Resolving this by setting language again in the onDestroyView function
#Override
public void onDestroyView() {
Utils.setLanguage(requireActivity());
super.onDestroyView();
}
I fixed the problem of pronunciation by changing the language of HTML using the lang tag.
HTML Language Accessibility