David Brown [Wed, 27 May 2009 20:57:36 +0000 (13:57 -0700)]
Temporary "double tap to answer call" UI for Sholes.
Since we're about to start dogfooding Sholes devices (which have no hard
send/end buttons), here's an ultra-simple onscreen UI that lets you
double-tap to answer an incoming call.
This is a TEMPORARY HACK until we have the real UI (which will go into
master, and may come from the moto team.)
Implementation notes and TODOs:
- The widget looks pretty ugly; I don't have any assets from Jeff (or
moto) yet so I'm just using the default button background.
There's also no visual feedback when you tap the button; that needs to
be designed too.
- Right now the double-tap-to-answer widget is only used on sholes.
At some point (once I get a nicer looking asset for the button
background) I *do* plan to enable it for ALL devices, so more people get
a chance to try it out. But in the long term this UI will only be used
on devices with no hard send/end buttons.
- I check for sholes devices by looking at the ro.product.device system
property. This is a temporary hack; in master these onscreen buttons
will be enabled via a special resource from the vendor/moto overlay,
but that overlay hierarchy doesn't exist yet.
- The double-tap detection code is a little ugly; I added a TODO about
extracting it out to a helper class that can listen for double-taps on
an arbitrary View, or maybe even a whole new "DoubleTapButton" widget.
TESTED:
- Built dream-eng, incoming call experience is unchanged.
- Built sholes-eng, the button appears for incoming calls, and
double-tapping answers the call. ("Answering" works in the emulator,
at least.)
- Made sure I didn't break the "touch lock" overlay for the dialpad.
David Brown [Thu, 14 May 2009 18:27:54 +0000 (11:27 -0700)]
Phone app: Initial *minimal* set of Phone UI changes for CDMA.
Fix a couple of CDMA-specific issues in the in-call UI:
- Add a new mode to the CallCard for the "generic call" state, where the
phone is in use but we don't know any specific details about the state
of the call (like who you're talking to, or how many lines are in use.)
NOTE this can't actually be enabled till the Call.isGeneric() API gets
checked in. (See the TODO comment in updateForegroundCall().)
- Make sure the "Manage conference" UI (which is GSM-specific) is never
enabled on CDMA phones
These changes are mostly untested, since I don't have a CDMA phone with
working telephony yet. (But the PhoneUtils/InCallScreen changes are
ultra-simple, and I was at least able to test the "generic call" UI by
temporarily hacking the code to pretend that Call.isGeneric() returned
true.)
I did at least make sure this doesn't break anything on GSM phones.
This change does NOT include:
- Automatically timing-out the "call waiting" connection if ignored by
the user. (The Moto team is already doing this, in the CallNotifier
class.)
- Make sure the "Merge calls" and "Swap calls" menu items are enabled
only when it's *really* possible to merge or swap. (The current logic
is GSM-specific.) Added TODO comments in PhoneUtils.java for these.
David Brown [Thu, 14 May 2009 21:43:28 +0000 (14:43 -0700)]
findbugs fixit: misc cleanup in CallCard.java:
- remove an unused variation of updateDisplayForPerson()
- fix potential NPE when calling Connection.getNumberPresentation()
- remove an unused member variable
- remove a couple of unused local variables
David Brown [Tue, 5 May 2009 04:15:05 +0000 (21:15 -0700)]
AI 148291: FIX 1827599 -- [STOPSHIP] Unable to make EC with non-TMUS SIM
Back in CL 138604, in response to bug 1695133 (from Vodafone), I removed
the "Dismiss" button from the "SIM network unlock" panel.
One consequence of that change is that there's now NO WAY to make an
Emergency Call if your SIM is network-locked and you don't know the PIN.
Unfortunately *that* behavior is unacceptable to TMUS.
So this change restores the "Dismiss" button for all products EXCEPT
vodafone. I do this by using a new config.xml resource called
sim_network_unlock_allow_dismiss, which is true by default, but set to
false in the vendor/vodafone/vfeu_overlay resource hierarchy.
TESTED:
- Got into SIM_NETWORK_LOCKED state by faking the event from the sim
- TESTED both possible values of sim_network_unlock_allow_dismiss.
- If true (the default), the "Dismiss" button is present, and
correctly dismisses the panel.
- If false (like in the vodafone product) there's no "Dismiss"
button.
- Also tested the layout (with the Dismiss button) in both landscape and
portrait modes.
There's nothing new to translate; this change doesn't add any string
resources.
BUG=1827599
David Brown [Fri, 24 Apr 2009 03:02:33 +0000 (20:02 -0700)]
Fix 1809590: text is truncated in a couple of "incoming call" menu items
The in-call screen has a couple of menu items with labels that are too
long for a single line. So for those items we turn off the icon (which
leaves enough room for 2 lines) and use explicit '\n' chars in the
string resources to break the text into two lines.
Unfotunately this never actually worked :-(
The InCallMenuItemView class has always forced itself into single-line
mode, which causes the '\n' chars in the text to be ignored.
The fix: *don't* force single-line mode for menu items that don't have
an icon. (If there's no icon, that means there *is* room for 2 lines of
text.)
TESTED: Confirmed that the multi-line menu items now look correct, and
the other in-call menu items are unchanged.
David Brown [Wed, 22 Apr 2009 01:49:45 +0000 (18:49 -0700)]
Re-apply fixes to the "SIM network unlock" UI (which were lost in the big CDMA merge)
CL 138604 in cupcake fixed some problems with the "SIM network unlock"
UI (bug 1695133.) That change was automerged to //branches/donutburger
in CL 139143, but it then got mostly undone when CL 144185 (the big CDMA
merge) went in.
This change manually re-applies the fixes from CL 138604,
this time in the donut git tree.
The fixes:
- remove an unnecessary setMovementMethod(null) call
- remove the "Dismiss" button
- minor layout tweaks
- minor comment improvements
TESTED: faked an EVENT_SIM_NETWORK_LOCKED event to bring up the
IccNetworkDepersonalizationPanel, verified the "dismiss" button is gone
and the soft keyboard comes up correctly.
David Brown [Tue, 21 Apr 2009 02:07:31 +0000 (19:07 -0700)]
Fix bug 1793462 (part 1): add a resource to disable the "SIM network unlock" screen
Some networks may not have the concept of "unlocking a SIM", in which case
we should *not* show the "Sim network lock" screen even if we get an
EVENT_SIM_NETWORK_LOCKED message.
This change adds a boolean resource called ignore_sim_network_locked_events;
if true, the phone app will ignore EVENT_SIM_NETWORK_LOCKED events.
The default value is false, meaning that a EVENT_SIM_NETWORK_LOCKED event
will launch the IccNetworkDepersonalizationPanel, and prevent the user from
doing anything else until they enter a valid SIM network PIN (i.e. the
current behavior.)
To change this behavior, just set ignore_sim_network_locked_events to true
in a product-specific overlay file.
TESTED: faked an EVENT_SIM_NETWORK_LOCKED.
With ignore_sim_network_locked_events=false, the
IccNetworkDepersonalizationPanel came up normally.
With ignore_sim_network_locked_events=true, nothing happened.
Eric Fischer [Fri, 3 Apr 2009 04:42:07 +0000 (21:42 -0700)]
AI 144355: Automated g4 rollback of changelist 144335.
*** Reason for rollback ***
Roll back US Spanish import because it made the build too big.
*** Original change description ***
Import US Spanish translations, and a few Japanese changes.
David Brown [Sat, 28 Mar 2009 03:45:30 +0000 (20:45 -0700)]
AI 143276: am: CL 143274 FIX 1741378 and 1702095: Emergency calls get made to the wrong number(!)
if you started out in airplane mode.
In some cases when we launch the EmergencyCallHandler activity, we were
launching it using the intent returned by getIntent(), which is NOT
necessarily the most recent intent we were launched with. (It's actually
the intent from way back when the InCallScreen first got created).
This has probably been broken since CL 132105, when we started keeping a
single InCallScreen instance around for the entire life of the phone
process.
The fix is to simply call setIntent() to stash away the new intent any
time one comes in via onNewIntent(). (The javadoc for
Activity.onNewIntent() actually suggests doing this.)
Watch out: Dianne says there's a known problem that the saved intent will
get lost if there's a configuration change. This is EXTREMELY unlikely to
be a problem for the InCallScreen, though, since the call to getIntent()
happens so quickly after the original onNewIntent/onResume sequence.
(I filed bug 1743425 about the ActivityManager issue, though.)
TESTED:
- Various incoming / outgoing calls
- Emergency call when initially in airplane mode
Original author: dab
Merged from: //branches/cupcake/...
Dianne Hackborn [Sat, 28 Mar 2009 01:26:13 +0000 (18:26 -0700)]
AI 143214: am: CL 143009 More work on issue #1739507 (kila-user build is too big): remove some unused application resources I found.
Original author: hackbod
Merged from: //branches/cupcake/...
David Brown [Fri, 27 Mar 2009 23:43:01 +0000 (16:43 -0700)]
AI 143274: FIX 1741378 and 1702095: Emergency calls get made to the wrong number(!)
if you started out in airplane mode.
In some cases when we launch the EmergencyCallHandler activity, we were
launching it using the intent returned by getIntent(), which is NOT
necessarily the most recent intent we were launched with. (It's actually
the intent from way back when the InCallScreen first got created).
This has probably been broken since CL 132105, when we started keeping a
single InCallScreen instance around for the entire life of the phone
process.
The fix is to simply call setIntent() to stash away the new intent any
time one comes in via onNewIntent(). (The javadoc for
Activity.onNewIntent() actually suggests doing this.)
Watch out: Dianne says there's a known problem that the saved intent will
get lost if there's a configuration change. This is EXTREMELY unlikely to
be a problem for the InCallScreen, though, since the call to getIntent()
happens so quickly after the original onNewIntent/onResume sequence.
(I filed bug 1743425 about the ActivityManager issue, though.)
TESTED:
- Various incoming / outgoing calls
- Emergency call when initially in airplane mode
BUG=1741378,1702095
John Wang [Fri, 27 Mar 2009 23:38:59 +0000 (16:38 -0700)]
AI 143181: am: CL 142924 Support DCM specific MMI network service.
IExtendedNetworkService has 4 MMI service interface used by PhoneUtils to put DCM related nw service.
void setMmiString(String number);
CharSequence getMmiRunningText();
CharSequence getUserMessage(CharSequence text);
void clearMmiString();
And the service is bind via "com.android.ussd.IExtendedNetworkService".
Original author: johnwang
Merged from: //branches/cupcake/...
Code Review / android / platform / packages / apps / Phone.git / log