Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix TelemetryService and applicationContext issue #265

Merged
merged 8 commits into from
Nov 1, 2018

Conversation

electrostat
Copy link
Contributor

Addresses: #263

Address issue where static applicationContext set by the activity is null, but service is still operating. Lifecycles are detached and can cause potential issues in lower API levels. Goal is to test and prevent crash from occurring. If possible, refactor all tangental code ran by the service to prevent this as well.

- add AndroidX for service testing
- checksLocationPermission test
- make locationPermissionCheck package-private
- remove null check from method
- move to getApplicationContext()
@electrostat electrostat self-assigned this Oct 29, 2018
@@ -181,6 +179,16 @@ boolean isTelemetryReceiverRegistered() {
return isTelemetryReceiverRegistered;
}

boolean locationPermissionCheck() {
Copy link
Contributor

@andrlee andrlee Oct 29, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since we've dependency on supportlib-v4 is there a reason why we're not simply doing:

Suggested change
boolean locationPermissionCheck() {
private boolean locationPermissionCheck() {
return ContextCompat.checkSelfPermission(getApplicationContext(), Manifest.permission.ACCESS_FINE_LOCATION)
== PackageManager.PERMISSION_GRANTED;
}

wouldn't ContextCompat handle if (Build.VERSION.SDK_INT >= API_LEVEL_23) logic on your behalf? Also if it does how do we test for that?

@@ -181,6 +179,16 @@ boolean isTelemetryReceiverRegistered() {
return isTelemetryReceiverRegistered;
}

boolean locationPermissionCheck() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we're changing method's visibility modifier in order to get it under test harness, we should always annotate it with @VisibleForTesting otherwise someone may think that we're not properly encapsulating our code. Now, another question is it really necessary to change its visibility in order to test it?

@@ -135,6 +139,17 @@ public void checksOnTaskRemovedCallbackWhenOnTaskRemovedCalled() throws Exceptio
verify(mockedCallback, times(1)).onTaskRemoved();
}

@Test
public void checksLocationPermission() throws Exception {
Intent serviceIntent = new Intent(InstrumentationRegistry.getTargetContext(), TelemetryService.class);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what are we trying to test here for? since permission is already granted with GrantPermissionRule how useful is it? Should we consider implementing a test when permissions are not present and try to verify the outcome/result with public APIs exposed by TelemetryService?

assertJ : "org.assertj:assertj-core:${version.assertJ}",

//AndroidX
androidXEspresso : "androidx.test.espresso:espresso-core:${version.espressoVersion}",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are these dependencies necessary to compile test code?

- remove unused rule
- remove unused dependencies
- simplify locationPermissionCheck
- unused imports
- remove unused import in test (not caught by local checkstyle)
@@ -181,6 +178,12 @@ boolean isTelemetryReceiverRegistered() {
return isTelemetryReceiverRegistered;
}

@VisibleForTesting
boolean locationPermissionCheck() {
return ContextCompat.checkSelfPermission(getApplicationContext(), Manifest.permission.ACCESS_FINE_LOCATION)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would you be able to test this fix on at API 19, 23, 26, 28?

Copy link
Contributor

@andrlee andrlee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd also love to see a couple of tests with activity when we start service before activity starts and after and ensure that everything woks as expected.

@andrlee andrlee merged commit 5636926 into master Nov 1, 2018
andrlee pushed a commit that referenced this pull request Nov 1, 2018
* Refactor TelemetryService out of static application context reference
* Add integration test with activity and service
* Fix potential issue with intent being null onStartCommand
@electrostat electrostat deleted the aa-migrate-getapplicationcontext branch November 1, 2018 13:48
electrostat added a commit that referenced this pull request Nov 1, 2018
- add #265 to changelog
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants