In the AOSP version of the email app, we don't by default
have any oauth providers. We should not display option
to set up your account with OAuth.
Change-Id: I6fc55ae4852ec76b7c34c09ac58a0e06e89affa7
Fix re-displaying the dialog on orientation change b/5622284
Add host/port when available b/4988512
Disambiguate intent between AOSP and EmailGoogle
Change-Id: Ideeda20dfd9bd0070998ccf42d8042765866ca0e
- Don't loop on the confirmation dialog
- Do a deep copy of the initial hostauth state
- Save the initial hostauth state on configuration changes
- Collect the user input before comparing the old state with the new
b/14285245
Change-Id: Ibc033fac525be2a4cb03c6a0d1e92254a2236b4c
(cherry picked from commit 294593c5f5)
- Don't loop on the confirmation dialog
- Do a deep copy of the initial hostauth state
- Save the initial hostauth state on configuration changes
- Collect the user input before comparing the old state with the new
b/14285245
Change-Id: Ibc033fac525be2a4cb03c6a0d1e92254a2236b4c
Unfortunately, there are problems with making a single
view handle all kinds of authentication and certificate
selection. The layouts for the account settings screen
on phones versus tablets are just too different. So
now the certificate selection code has moved back to the
fragments themselves, and the authenticationView only
handles passwords and oauth.
Change-Id: I1ef0c69687a00029717b836458c85c1b0667ff95
Now the password entry is removed from AccountSettingsBasics,
and the user is taken to either SignInActivity or AccountSetupType
after hitting the next button. This is a lot closer to the
desired setup flow as it allows for oauth signin.
Ideally this is not what we will ship for Algol, but it put us
in a state where we could ship if we had to.
Change-Id: I5b28bccd27c515572e4947ca877bd1772732507d
Putting authentication in a fragment was a problem, it
means that we need fragments as children of other fragments.
While this works in theory, it adds a lot of complexity.
Now, authentication is done with AuthenticationView,
which is just an extension of LinearLayout.
Currently, this does not yet handle adding certificates
for exchange accounts, but I'll fix that ASAP. As it is,
this is better than the current state, which crashes on
account setup 100% of the time.
Change-Id: I4274e7250f97012c3dc476003fd36fb960f2b728
This is one fragment that holds all types of
authentication information, e.g. password,
OAuth info, and client certificates. What gets
displayed depends upon the type of account it is
dealing with.
So far this is only used in AccountSetupIncoming,
but later it can be added to other settings fragments.
There are still some issues with this, but I'd like
to check it in sooner than later to unblock other
work.
Change-Id: Iea675ad5c1727f32ca0baa270dfa793ab7109993
This will keep it from being recreated quite as much while off-thread tasks are possibly mutating it.
Change-Id: Ic9873489906339c33a76b8a600c0fc28016debc4
There is now only one LogTag class. The static initializer of
GmailApplication (existing) and EmailApplication (new) will now set
the log tag to "Gmail" and "Email", respectively. Up until that code
is run, it will be "UnifiedEmail".
"setprop log.tag.Gmail VERBOSE" (or .Email) will trigger all logs to
be printed as long as they go through LogUtils, regardless of what tag
is used by that individual log. This lets us still turn on logging
everywhere in one command, but also lets us use more descriptive tags
(like the class name).
And since we no longer have three com.android.mail.utils.LogTag
classes, builds will be much easier.
Also, we now use LogUtils everywhere.
Change-Id: I55f1c7a66ce50ead54877a13e40256422a56dc39
This is a common root cause with monkey crashes.
Fixes b/5628984 com.google.android.email: java.lang.NullPointerException: Unable to start activity ComponentInfo{com.google.android.email/com.android.email.activity.setup.AccountSetupIncoming}: java.lang.NullPointerExceptionat android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1955)
Change-Id: Ib3ac5c62b72662402c7d5df4e5d895beaf324197
- properly put actionNext on most fields
- make sure actionDone doesn't do funky things with focus so that a
non-editable field gets focus. we may want to consider not making this
focusable in the future.
Bug: 5367827
Change-Id: I4e7bb13801d96a4f1e6fd02a2d43713200738b18
* We were using the getSelectedItem() from the deletion spinner to
set the account's deletion policy, even if that spinner was
invisible (which it would be for IMAP).
* The result of this is indeterminate; sigh
* The fix is to make sure the spinner is visible before using its
value
Bug: 5216422
Change-Id: I7e44b5e8127f5277693f7e962899e8642be55239
Adding and removing a star triggers the appropriate accessibility
In incoming/outgoing settings, added EditText contentDescriptions.
Change-Id: Ibab461f1425b3ebf3579ebc1d0b36d1a9a5efdb2
On phones, opening "incoming settings" no longer immediately displays
the warning message associated with editing the username field. It now
only displays when the username is focused by the user.
Bug: 4282856
Change-Id: Ic0a74fa91a0f9cff66565372872e182a0eaec779
* Remove per-store limitations
* Use constants for VISIBLE_WINDOW, rather than having the
potential for differences between Stores
Change-Id: Idd5e0874bba6e3390e4f093bcb03f4b1bb399c11
