Popping a brick from any location $(i, j)$recursively pops all bricks within its flood pool, defined as the set of the origin brick and its neighbors (and their neighbors thereof) who share the same color as the brick at $(i, j)$. The game defines a neighbor of a block at $(i, j)$to be any block $\in \{(i + 1, j), (i - 1, j), (i, j + 1), (i, j - 1)\}$. A pop is considered valid (and thus can only induce a state transition) if the size of the flood pool set is greater than unity.
A contraction process follows each removal of a flood pool. Columns are contracted if every element in the column (after the pop) is null, causing every element in columns to the right to be shifted left into the cleared column. More precisely, a column $j$consisting only of empty elements is contracted, causing all elements formerly located at $(i, j + 1)$to have a new location $(i, j)$. Rows are contracted if there exists defined colors anywhere above empty colors; e.g. colored bricks at $(i, j)$and an empty brick at $(i + n, j)$for any $n > 0$. The colored bricks are vertically offset to a new index such that no empty elements exist below it.
The board is considered to be solved state when there are zero non-null elements left on the board. This state can only be reached by a sequence of valid flood pool pops.

The solution search space is very large. Any input board configuration can have up to 10-20 available moves (i.e. valid coordinates at which a flood pool pop can be executed). This number is higher when the board consists of more colors (the maximum such number of unique colors is six) or when the board consists of no null elements (i.e. when the level is first started). The size of the search tree is exponential in size, and any search algorithm that exhaustively explores all possible solutions is necessarily exponential in asymptotic complexity.
Any input board configuration can have several valid solution paths. Thus, it is wisest to fully explore one potential solution route and check its validity at the end (as in a depth-first search) rather than attempting to fully exhaust exploration of each possible move at each step (as in a breadth-first search). Using DFS allows us to arrive at a solution much faster, but there is no guarantee for a path-length optimized solution (i.e. solving a board in the minimum number of steps).
The game is structured in such a way that it is difficult to use any heuristics to intelligently traverse the search tree. The gameplay rules are simple; state transitions are pure and can be fully described by any current state of the board. The game does not attempt to be "clever" in any way to suggest that one type of state transition is more likely to solve the board than another. Thus, an automated solution can only optimize the performance of a (worst-case) full traversal of the exponentially-sized search tree.

def serial_solve(board, steps=tuple([])):
    if board.is_solved():
        return Solution(steps)

    possible_solutions = (
        serial_solve(new_board, steps + (step,))
        for (step, new_board) in board.available_moves()
    )
    valid_solutions = (
        steps
        for steps in possible_solutions
        if not steps.is_empty()
    )

    return next(valid_solutions, EmptySolution())

def parallel_solve(board):
    queue = multiprocessing.Queue()

    processes = [
        multiprocessing.Process(target=solution_search, args=(queue, [single_start_point],))
        for single_start_point in board.available_moves()
    ]

    for p in processes:
        p.start()

    solution = EmptySolution()
    num_failed_solves = 0
    while True:
        if num_failed_solves >= len(processes):
            break

        try:
            solution = queue.get(block=False)
            if solution.is_empty():
                num_failed_solves += 1
            else:
                break
        except Queue.Empty:
            pass

    for p in processes:
        p.terminate()

    p.join()

    return solution

Taking and parsing a screenshot of the board from the device, and creating an appropriate Board instance to describe the input
Running the solver on the board to generate a sequence of steps to the solution
Executing the solution on the game board by simulating touch events on the connected device via ADB

Website

Github

Twitter