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
Fixes b/9193813. Previously we returned
a value from the database in all cases.
This meant that system folders were not
translated.
Change-Id: Ife568651886bfb6de76221b8bc5d013dac8fa21a
To streamline our build, I've gone through
and eliminated the redundant build directory.
Strings in build/res have been moved into the
regular res/ directory and the Android.mk
file has been updated to no longer use the
non-existent build directory at all. Fixes b/9105428.
Change-Id: I93288068dceb13ad0a9a5396eb88335e3ecd65f1
Tony Mantler