b/17367647
The friendly name paired with the email address is now considered
optional when creating a new email account.
Change-Id: I9398ae48e29ee0554efc9c46e9f2f380e7f17cf9
There is still work to be done here:
* The debug setting is not persisted in Exchange, so if
the exchange service is killed, when it restarts the logging
will not be active.
* Nothing in Exchange actually does any additional logging
if this logging is turned on.
Change-Id: Ic578e6956f70dd47fba9b2895385312f71c47abf
Allow the compose activity, that the account reconciler attempts
to enabled/disable, to be able to be specified via resources.
This allows the various build targets to change the activity that is
enabled/disabled, or to not attempt to do this at all
Change-Id: I7c91c2c179316a3aac910a38d7dd0025076b085a
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
b/14239989
We take advantage of ListView's feature that displays an entirely different
view in place when the backing Adapter is empty. The empty view is simply a
TextView displaying "No quick responses available".
Change-Id: I244ffd21fc4c1557c73979d4bb7c99306b11ebb2
b/14255447
The password label, edit text, and clear button were not
lining up correctly. Also, there needed to be more space
around the password edit text.
Change-Id: I71864733457b3b599160a6d9a44d48d2e23961ce
Now, if you fail to authenticate on the credentials fragment,
instead of taking you to the full accountSetupIncoming,
it just takes you back to the credentials fragment with
a warning that your password is wrong.
Also, make it so that pressing "next" on the password IME behaves
the same as pressing the Next button.
Change-Id: Ice91c842659c33ba6f8ac876356a79265c703e2e
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
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 just adds an oauth button to the accountSetupBasics
screen, which will launch a webview and go to the google
authentication page.
Change-Id: I09d5182fa6081fb94b40e7910b71afbbee70387e
The user no longer has control over this. Now, the "default" account
(which is only used for prepopulating the name of new accounts is
either the last used account (to be defined), or the first account in
the database.
This removes a setting, and simplifies a lot of code.
We may also want to auto-select the default account when entering the
compose screen from the combined view, but we do not currently have
an easy way to do that.
Bug: 7442992
Change-Id: Iff5bb36d8cbd327334211b670fa4851cbda6b9a0
