Elimination of Lint warnings

[gerhardol]

Android Lint as well as Android Studio (IntelliJ) Inspect issues.
(Inspect and Lint partly use the same engines, but Inspect has some separate checks and configuration is partly separate).

The changes that has required more manual changes or should change something has been submitted as separate PRs. This PR is based on open PRs too (those were separated over time). Some files may give merge conflicts, like the build.gradle files that have been changed in many commits and branches.

The PR is big, but the alternative would be to submit 96 sequenced PR, as the changes to some extent are related. Most changes are relative easy to review, the changes are grouped per commit, review per commit can be done. (I recommend that viewing changes is done offline.) Certain commits can be reverted

The intention has been to have a clean Lint report, to be able to see new issues. This is almost the case, one error left. The GradleCompatible warning should be handled, but I have not found how this should be done. Froyo has a GradleDependency warning too, due to Google not supporting 2.2 and that the Lint check there is incorrect.

The out-of-the-box configuration for Lint has been used as much as possible, with minor adjustments (regardless of what I personally think of some of the issues). The strategy has been to fix as much as possible of the warnings, suppress in the code where reasonable and overriding in build.gradle, lint.xml or Project_Defaults.xml for general changes.

Related to the lint, the @TargetApi() override was removed. (See the commit message for explanations there)

The outcome of the review has been a few optimizations and improvements. This PR has few improvements in itself. However, it greatly simplifies finding new issues. Currently, you do not know if issues in code you are working with were there before or not. Making the changes once limits the "background noise" long term.

This has been tested in GenyMotion emulator on 7.0 and 2.3, as well as Sony Z3 6.0. However, I have separated commits and rebased several times, the final version is not separately tested much yet.

[davidedelvento]

So how about merging this PR after the next release and in the current beta?

[gerhardol]

@davidedelvento
That is my proposal too, make a new beta quickly after.

I could try to break out some specific changes, but it will not give so much.

[gerhardol]

@jonasoreland @davidedelvento
I will merge master and check for newly added issues before merging

Should this be squashed or not?
There are many commits, they have information why a change was made though.

Should this be merged to classic as well as ng?
If only ng, it will be hard to apply patches for the branches.

[cmmata]

My personal opinion: it's better to add all commits rather than squash to only one, because:

• In one squashed commit, you normally loose commit messages. Or it's more difficult to see which file is affected for every commit message
• If one change makes problems, you can see exactly what is changed and revert that files. If it's a big squashed commit, it's more difficult to find problematic files and revert them.

And the second question, I think it will be better to merge in Classic and NG. If someone needs to make a change in classic branch, it will be nice to have that warnings solved.

But it's only my opinion :)

[gerhardol]

Sync merged with master, reviewed changes. Will test the updates a little more before merging to master.
Meanwhile, the branch is merged to 'master_ng' branch, that also raises the minimal SDK version to 21. For @cmmata to start with.

[davidedelvento]

I agree with @cmmata regarding squashing. In fact, in my git merge I always use --no-ff.

Regarding merging this in classic too, if you could merge in classic without raising the minimal Android version required, I'd say it makes sense to have it there. Otherwise, it's mixed bag, I see the usefulness of having this, but do we want to cut people out? But in the end, I am neutral. I am not planning to do much with classic, so I'm fine either way.

[gerhardol]

@davidedelvento
Minimal SDK is not raised (there are lints suppressed due to minimal in latest is 15 and minimal in froyo is 8).
It is much easier to cherry pick corrections from one branch to the other so I definitely want this. For instance for Synchronizers, sensors. A little more testing first.
Maybe even the AppCompat changes should be merged to classic for that reason (but the "views" will likely need to be rewritten anyway).

[gerhardol]

Superseded by #671