| ad44cda82fe6ec5ee090115129223c6314f9e1bb |
|
29-Jun-2015 |
zafir <zafir@google.com> |
Minimum viable Android M runtime permissions handling for H.
Creates new activity for permissions handling: both checking
for permissions and handling error condition when critical
permissions are not present. The reason for creating a
new activity is so the app does not attempt to continue
executing OnCreate, OnResume etc, which opens
the camera while the dialogs are showing. This should
not slow the app down because the permissions activity
will only run when a) the first time the app has
insufficient permissions and b) when a critical
permission is missing and the app needs to shut down.
Bug: 21273463
Change-Id: I603acfb3057ba26b9cfa7935eb4cb24b5d547cb5
/packages/apps/Camera2/src/com/android/camera/settings/Keys.java
|
| 4368ec0368f69e7604403b4a6db6f1e3123a1814 |
|
12-May-2015 |
Gabriel Nava <gnava@google.com> |
Ensuring the right HDR icon is shown on camera switch (camera-haleakala)
- When switching cameras HDR+ icon was always shown in disabled state regardless of the actual support mode
- Existing boolean setting to track device's HDR support is not enough
- Changing global device's HDR support setting to string that can hold no-hdr, hdr or hdr-plus values
Bug: 21037428
Change-Id: Ia9cf0484879a22a27e4deb0e4aa066ec806a43e6
/packages/apps/Camera2/src/com/android/camera/settings/Keys.java
|
| ce9ef4e3528e5599773809f74657b798c370aad2 |
|
01-May-2015 |
Gabriel Nava <gnava@google.com> |
Disabling non available options instead of hiding when hw support is present (camera-haleakala)
- Global scope property persists the support of flash and hdr for the main camera (back)
- If option is not supported at all, option is hidden
- If option is supported in at least one camera but not supported in current module, option is disabled
- If option is supported in current module, option is enabled
- Avoiding race condition where CameraAppUI.applyModuleSpecs was bein called multiple times simultaneously for the same change
- Adding a check so BottomBar UI is updated only when there's a scope (module/camera) change, unless...
- Scope check can be requested within same scope for settings change
Bug: 20630060
Change-Id: Iac5fa2658f04fe8329a2232fb0d5b11d20e566a2
/packages/apps/Camera2/src/com/android/camera/settings/Keys.java
|
| fb0496133a0b4b526dc70f6447bd4b97d95de95f |
|
12-Jan-2015 |
Senpo Hu <senpo@google.com> |
Move FirstRunDialog to app layer.
The first run logic should live in CameraActivity. This refactoring
could clean up CaptureModule and PhotoModule.
* Introduce ResolutionSetting class.
* Introduce OneCameraManagerImpl for camera API 1.
Tested and verified this works on K / L devices.
Change-Id: I11a968a9346b520dee23fc4591a73bb483c43246
/packages/apps/Camera2/src/com/android/camera/settings/Keys.java
|
| 6293c579bce8356f10cda31637917537a4501437 |
|
13-Oct-2014 |
Alan Newberger <alann@google.com> |
Refine in-place conversion semantics for Settings
Since settings are now stored as strings, avoid app crashes
for settings which are still around as other types, and just
treat it as if those settings are absent (return default). This
requires re-working the version number tracker itself, which
is done by making it a new key and migrating just the old
key in the getLastVersion override. This is somewhat cleaner
and overall the change should increase stability given the
change to use in place values of different types.
Bug: 17949433
Change-Id: Icaf0d9653eabb9e144f3946a51b4038d3ed48ea9
/packages/apps/Camera2/src/com/android/camera/settings/Keys.java
|
| 65c00136cde07e050d05e3da61876199df90dd18 |
|
09-Sep-2014 |
Senpo Hu <senpo@google.com> |
Set video quality pref default values at startup.
The problem of the old approach is the default values never got set
until switching on video module.
The caveat of the this CL is that the default value tweak is only applied
for Shamu. Rather than basing on device model string, detecting
CamcorderProfile capability is a better way to get this job done. However,
|CamcorderProfile.hasProfile| needs camera id info so I'd argue this CL
is good enough for the Shamu/L release.
Bug: 17060480
Change-Id: Ia53ff6aecad44fe7a32257fa1415163f167c09bf
/packages/apps/Camera2/src/com/android/camera/settings/Keys.java
|
| 20571ffe611c58d6d77e8d029b455f18c10181d5 |
|
19-Aug-2014 |
Senpo Hu <senpo@google.com> |
Change Shamu's default video resolution setting.
Bug: 17060480
Change-Id: I5ce8d2d2960d21856c0f13e9599d80b0edc03ec9
/packages/apps/Camera2/src/com/android/camera/settings/Keys.java
|
| d020fbf12aff20c0a4b5cd1df67da6c2054e7408 |
|
17-Jul-2014 |
Spike Sprague <spikuru@google.com> |
clean out timelapse stuff from codebase
Change-Id: Ibcf07302f3eea2800d1f36c918ffe1c3d93b8018
/packages/apps/Camera2/src/com/android/camera/settings/Keys.java
|
| 6190c36db653e848f29d1caefc4fa1bb61e8a662 |
|
13-Jun-2014 |
Erin Dahlgren <edahlgren@google.com> |
New Settings API
Based on discussions from last week and comments on the design doc,
this api begins to implement the following:
1. Adds a "Scope" variable to api, which tells the SettingsManager
whether the setting can be stored globally (so that it is visible
to all parts of the app), or per-camera, or per-module, or per-
custom scope that the api user provides.
2. Separates keys and default values from SettingsManager,
to make it easy to add new settings/defaults from third party
modules.
3. Stores all settings as strings, to avoid upgrade errors, and
handles casting to type requested. Only String, Integer, and
boolean are supported.
4. Opens SharedPreferences files on demand, depending on scope
argument.
5. Creates a "DefaultsStore" to hold the defaults and possible
values of a setting. Then a user can request the default or
possible values of a setting at any time.
Change-Id: I03e0e1dd0955c519f54112e89716014aa963a425
/packages/apps/Camera2/src/com/android/camera/settings/Keys.java
|