antiqueeverett / back-of-device Goto Github PK

while in the background, application continues to play music.
application can no longer be controlled when returning from background.

Currently, sluggish AE helps us detect taps, but can be weird in low-light situations or if the camera has been improperly configured before (stuck on wrong settings, no idea how to reset them). Maybe we can find a way to set autoexposure to a sane default range or value to create more consistent results.

LumaAnalysisRunnable reports luminance as 0 because on every new captured frame, the memory address of mImgGray changes.

Possible solutions:

• Write new image values to existing matrix (slow as hell, Mat.put doesn't want to work with byte arrays for some reason)
• Don't give LumaAnalysisRunnable the image, instead give it a reference to the Backhand class (dirty)
• Create a method that updates the image (literally just came up with that as I was typing this and it seems to be the best solution)

• Swipe from the bottom: easiest case
  • initially only lower third will be dark
  • then lower 2/3
  • then full image → can we stop here?
  • then upper 2/3
  • then upper 1/3
  • then light
• more complicated: swipe from above:
  • initial state is completely dark (finger covers sensor already)
  • then lower 2/3
  • then lower 1/3
  • then light
  • → less data points, less accurate detection..?
• Sideways swipes: problem: left-handed vs right-handed
  • can't rely on finger clearing the camera before the swipe
  • different angles
  • possible solution: same logic as downward swipe, but loss of accuracy

light deviations outside finger movements trigger unintended application actions.
currently application does not function properly under low lighting conditions

after installation the first run results in an unexpected crash

• [] remove all ignorable files from the working tree without breaking the project

as of yet the application can not be terminated

Currently, tap timing is based on millisecond measurements. However, how fast a device delivers images is up to its sensor and processor, and a low end device such as the Moto X 2013 may take 150-250 ms between images (including luminance calculation), while a newer device (e.g. with more cores, therefore the ability to compute more luminance segments concurrently) may be done much quicker.

Proposal: Make the timing frame based instead of time based, or use a combination of the two. I.e.:

• determine the limit at which gestures can be reliably detected
• run a timing loop at the start to determine fps and/or lock them using CaptureRequest.CONTROL_AE_TARGET_FPS_RANGE (will not influence computation time though)
• artificially skip frames for "too fast" devices? (doesn't sound like a good idea...)