| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: I19e9dfaf248fce7376b124ee91de7e73fdc99fb3
|
|
|
|
|
| |
Depends-On: I5b1dccb5d103ece3112acf38889bae16273b092f
Change-Id: I116aed2bb805f723a5bf2ec9eb94257de0b4a7b5
|
|
|
|
| |
Change-Id: Iebfa52cb849d69974c94902b0b020893cf5618a3
|
|
|
|
|
|
|
|
|
|
| |
+ The SIM lock option will now appear if there is any SIM with locking
capabilities.
+ Also, if the first slot does not have a SIM in it, then the SIM lock
screen will disable the ability to lock the first slot.
Bug: 18473536
Change-Id: Ib4e0ed6e94b00bc07c9febdad433fdb3c55294b8
|
|
|
|
|
| |
Bug: 18408617
Change-Id: Iea14f40082aa9b7fd6c1925ee5ca5e6bc6841140
|
|
|
|
|
| |
bug: 17575308
Change-Id: Idd98aa46c15a9219ccf28091c62602ac8bf16c62
|
|
|
|
|
|
| |
This reverts commit 1285f74fcb6a8bf080c224e5a36db00ab1167d4c.
Change-Id: I366556368a9c429d8c356bcdb8e29af9c6c4c71e
|
|
|
|
|
| |
bug: 17575308
Change-Id: I7773965094510999bfce8fc6b2b31ba6ce496653
|
|
|
|
|
| |
Bug: 18147652
Change-Id: I89d3ffb0b1451d263d7c913ac210d52d5308f3c0
|
|
|
|
|
|
|
| |
- revert changes from the CL for Drawer implementation.
- we cannot convert those Activities to fragments as they are running in the Phone process
Change-Id: I7e4033bc9b53daa7e7aa6f1fd74576375cde88e9
|
|
|
|
|
|
|
| |
- remove Intent declaration in favor of a Fragment
- make PhoneFactory.getDefaultPhone() call work again
Change-Id: Ie1cb6894b0c00361c451af1f8542c905213a3c97
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- get rid of PreferenceActivity as much as we can and use fragments instead
- add Drawer widget
- add Dashboard high level entry into the Drawer (but this is work in progress and would be done in another CL)
- add bypass of fragment's Header validation when launched from the Drawer but *force* validation if external
call thru an Intent
Be aware that WifiPickerActivity should remain for now a PreferenceActivity. It is used by SetupWizard and should
not trigger running the SettingsActivity's header building code. SetupWizard is a Home during the provisionnig process
and then deactivate itself as a Home but would make the Home header to appear in the Drawer (because momentarily we
would have two Home).
Also, verified that:
- the WiFi settings still work when called from SetupWizard
- when you have multiple Launchers, the Home header will appear in the list of Headers in the Drawer
Change-Id: I407a5e0fdd843ad7615d3d511c416a44e3d97c90
|
|
|
|
|
| |
Bug: 9928717
Change-Id: I73718c9e6a8aa7244097e0dd4593a6226ff0ac08
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lock SIM card checkbox is enabled always which results in
allowing the user to change the state even before the
previous change has been completed successfully. Due to
this option, UI ends up in state where it can send
disable Lock SIM card twice resulting in operation
not allowed error from modem.
Change-Id: I0f4a344a8d76720e75accf3a763c3d0e940a0dca
Author: Jeevaka Badrappan <jeevaka.badrappan@intel.com>
Signed-off-by: Xiaokang Qin <xiaokang.qin@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 9954
|
|
|
|
|
|
|
|
| |
This fixes a bug where the SIM enable checkbox was showing the
wrong state. The code now registers for state changes and updates
the checkbox state appropriately.
Change-Id: Icd4f040140e9f71e75e288968ee7ae616dfd08ce
|
|
|
|
|
|
|
|
|
|
|
| |
In security setting, if user change orientation during entering
pin code, the change will not apply successfully, it is because
the entered pin codes has not been saved and restored when
application was re-create after changed orientation. So we save
entered pin codes and restore them in onCreate when application
is re-created.
Change-Id: Ia8a3fb3ee75185ce028104487377e47f272905ce
|
|
|
|
| |
If the monkey is running, exit the SIM lock settings activity.
|
|
|
|
| |
State of dialogs was not properly maintained across pause/resume.
|
|
from donutburger.
Automated import of CL 144245
|