GitLab

Even less RAM required to hang onto this in the lockscreen.

Bug: 18369196
Change-Id: I7ed5ad098b77c96b40d0b76e4a20a7fea12e362a

Since SysUI holds these bitmaps in memory for jank-free
drawing, these pixels are just wasted RAM. Since the
transition code assumes uniform square bitmaps, these are
all 64x64dp, which is still a teensy bit wasteful but much
better than before (144x144dp).

Bug: 18369196
Change-Id: Idf10b2048190ac44eff3e5da467149c460067347

b/18239042

Change-Id: Ia59b4c10551038bf2cbe9b9770f21c63f49731f3

b/18239042

Change-Id: Ia59b4c10551038bf2cbe9b9770f21c63f49731f3

Our .01 tolerance omits valid 4:3 previews when the image capture is
more than 0.01 over true 4:3. Relax matching in Glacier just for
affected builds.

Bug: 18241645
Change-Id: I5868bc9535e4c9bb886f0de0daf0e83cd2f4dc78

Update picture size before applying parameters prior to starting preview.
This is required to avoid a 640x480 default picture stream on the Nexus 4
which is causing lowered preview frame rates (for unknown reasons).

Bug: 18227551
Change-Id: I2b7648146ff57d5a7d78a22f884643c6d62497e6

  Bug: 18172081

Change-Id: I26b09f19757e059d3567b3cb707592696531d0b3

See frameworks/base commit 33253a4baa6279f81a73425b49dfb6abe5f5416e
for details.

Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: I70a3ad8a9264c320b5e2d6a9097a05d473e4fcfa

  Bug: 18121865

- Make sure we announce that the module is exiting.
- Send postview image to wear device.
- Make sure we can take a picture when timer is on.

Change-Id: I1cbc2e9a1725fdd6d8724ce93f547c87eab8b4aa

    Bug: 17868158

Part of a multi-project commit, along with ag/575889
Adds a helper function to identify when the Android device
is a Nexus 9.

Change-Id: I36c3b6e4472d08d1be7b1197fd62f4766fcc81ed

bug: 18122644

Change-Id: I2681e5f104527553c4f6d71d96c0b659685813fa

In QueryTask we pick the id from the first result and consider it
the max id, yet we query ordered by date taken. On most phones
they're the same but by correcting the query to satisfy the
assumption in QueryTask, we remove costly scenarios where most
photos are reprocessed in LoadNewPhotosTask. One line fix in
LocalMediaData with more verbose logging added in CameraDataAdapter.

Bug: 17437217
Change-Id: Ia643f38d1bfb77ff0beaba989f0effe9a4dec31c

bug: 18115448
Change-Id: I9d1caaa0903d6f3c2c47ca3e8457a4f85aad910c

Show camera fatal dialog to guide users exiting the app when
1) camera framework throws RTE or
2) DispatchThread job is timeout.

If users hit home button while error dialog is shown, just exit
the app.

Bug: 16189216
Change-Id: Ia0f1c64d452735ec62549f50ab62646d8d873c65

Conflicts:
	src/com/android/camera/CameraActivity.java

Merge "When option buttons are disabled, make sure the HDR / HDR+ button has the correct icons." into ub-camera-glacier

  Bug: 18105354

Fixes the bug where we try to cast a context to an activity.

Change-Id: I3e82a2cda5fe004768276a4d48c07d75738b2a5e

bug: 18104680
Change-Id: Ifd56369ca8177d40317f6af76bbc55a2110d6f5c

Making it a bit easier to compare rotation vs capture metrics.

Bug: 18055323
Change-Id: I15904a00fcb463739b5d7e4c2ca7627be2ecb2b7

Change-Id: I2e1a05b9670c01c9729ed9e7b8b146add95ab88f

  Bug: 12805279

This CL fixes all known activity leaks that occur from our
app. One leak remains that is caused by Camera Framework and
is tracked under b/18077200.

For details on how to find and chase these leaks down, see
http://go/camera-activity-leaks

Change-Id: I9608e2fcf77fe97528b883ed40e0c08bbbf45bdf

This can return null in some scenarios and other invocations do
null checks, one was missing here.

Bug: 18005946
Change-Id: I14c4b31569ace7e84886228a638757ab1cd4710f

No glacier incidents but with hundreds of Fishlake incidents
implying that sometimes we fail to find the preference to
remove, protect against nulls here to avoid crashing in
Settings.

Bug: 14625519
Change-Id: Iebc1a103abae7524e6ab0aca96d5c2479e62d9ee

Log all orientation values to diagnose capture orientation behavior.

Bug: 18055323
Change-Id: If63455104f7b96f5797f2651d1aadcadee67e1af

Saw just one case of this and my hypothesis is that it was due to
another now-fixed exception resulting in a partial upgrade. But
in no case should these remove issues fail, so fixing to remove and
return the default if the underlying value is not readable. There
is some possibility for behavior error in this case since perhaps e.g.
a String-based 'true' was written and we upgrade instead to a default
'false', but allowing users to enter camera is better and I've audited
all uses of these, behavior should be fine/recoverable vs and
preferable to startup crash.

Bug: 18042161
Change-Id: If2453a819311bfd9233fdf65d7a97d8a243b393a

   Bug: 17883828

There is UI path to start the secure camera app from the lock
screen, and then unlock the phone and find the secure camera
app on the task manager.
This live instance of secure camera app is confusing to the
user who is expecting to interact with a full camera app.

This fix kills the secure camera app when the phone is unlocked
and ensures that the user cannot easily restart the secure
camera app from the currently running tasks in task manager.

Change-Id: Ia6a6d077c460e66807d4be9836fe192184aa8eaf

    Bug: 17952997

The logic to show and disable the flash button was NOT paired
with the torch button and sometimes allowed the enabled
torch button to be shown, even the flash button was disabled.
A bit confusing, since the torch and flash button look exactly
the same.

Torch button logic to show/hide and enable/disable now follows the flash
logic.

Change-Id: Ie14b07815b6d5e1f8d7ce792ef9ee36dfdf8e3ad