Add web server for app downloading and small fixes
Merge request reports
Activity
26 } 70 27 71 if (SDK_INT >= 29 && (checkSelfPermission(ACCESS_FINE_LOCATION) != PERMISSION_GRANTED)) { 28 @RequiresApi(29) 29 private void requestPermissions() { 30 if (checkSelfPermission(ACCESS_FINE_LOCATION) != PERMISSION_GRANTED) { 72 31 requestPermissions(new String[]{ACCESS_FINE_LOCATION}, 0); 73 32 } 74 } 75 76 public void onButtonClick(View view) { 77 button.setEnabled(false); 78 if (hotspotStarted) viewModel.stopWifiP2pHotspot(); 79 else viewModel.startWifiP2pHotspot(); 33 if (viewModel.needToAskForEnablingWifi()) { 34 Intent i = new Intent(Settings.Panel.ACTION_WIFI); 71 105 status.setValue(app.getString(R.string.callback_waiting)); 72 requestGroupInfo(1); 106 requestGroupInfo(1, networkName); 73 107 } 74 108 75 109 @Override 76 110 public void onFailure(int reason) { 77 if (reason == 2) requestGroupInfo(1); // Hotspot already running 111 if (reason == 2) requestGroupInfo(1, networkName); // Hotspot already running 78 112 else releaseWifiP2pHotspot(app.getString(R.string.callback_failed, reason)); 79 113 } 80 114 }; 81 115 try { 82 wifiP2pManager.createGroup(channel, listener); 116 if (SDK_INT >= 29) { 117 String passphrase = getRandomString(8); 25 26 @Override 27 public View onCreateView(LayoutInflater inflater, ViewGroup container, 28 Bundle savedInstanceState) { 29 viewModel = new ViewModelProvider(requireActivity()).get(MainViewModel.class); 30 // Inflate the layout for this fragment 31 return inflater.inflate(R.layout.fragment_server, container, false); 32 } 33 34 @Override 35 public void onViewCreated(@NonNull View v, @Nullable Bundle savedInstanceState) { 36 super.onViewCreated(v, savedInstanceState); 37 qrCode = v.findViewById(R.id.qr_code); 38 urlView = v.findViewById(R.id.url); 39 40 String text = "http://192.168.49.1:9999"; mentioned in commit eaddc3c9
124 131 } 125 132 } 126 133 127 private void requestGroupInfo(int attempt) { 134 private void requestGroupInfo(int attempt, @Nullable String networkName) { 135 Log.e("TEST", "requestGroupInfo attempt: " + attempt); 128 136 GroupInfoListener listener = group -> { 129 if (group == null) { 137 boolean retry = false; 138 if (group == null) retry = true; 139 else if (networkName != null && !networkName.equals(group.getNetworkName())) { -
What does this name comparison logic do?
I made some changes that caused the app to crash, and after relaunching it would fail to get the group info. But in the log it looked like it had found a hotspot already running, and then failed to accept the group info because of the network name comparison:
2021-04-20 11:21:30.748 14475-14475/org.briarproject.hotspot E/TEST: networkName: DIRECT-3m-LBoOcm0ZcD 2021-04-20 11:21:30.748 14475-14475/org.briarproject.hotspot E/TEST: passphrase: jpA3xmt6 2021-04-20 11:21:30.767 14475-14475/org.briarproject.hotspot E/TEST: requestGroupInfo attempt: 1 2021-04-20 11:21:30.791 14475-14475/org.briarproject.hotspot E/TEST: received networkName: DIRECT-nH-D561ZZO3Ey 2021-04-20 11:21:30.791 14475-14475/org.briarproject.hotspot E/TEST: received passphrase: S3Hy7r1K 2021-04-20 11:21:31.793 14475-14475/org.briarproject.hotspot E/TEST: requestGroupInfo attempt: 2 2021-04-20 11:21:31.798 14475-14475/org.briarproject.hotspot E/TEST: received networkName: DIRECT-nH-D561ZZO3Ey 2021-04-20 11:21:31.798 14475-14475/org.briarproject.hotspot E/TEST: received passphrase: S3Hy7r1K 2021-04-20 11:21:32.801 14475-14475/org.briarproject.hotspot E/TEST: requestGroupInfo attempt: 3 2021-04-20 11:21:32.807 14475-14475/org.briarproject.hotspot E/TEST: received networkName: DIRECT-nH-D561ZZO3Ey 2021-04-20 11:21:32.807 14475-14475/org.briarproject.hotspot E/TEST: received passphrase: S3Hy7r1K 2021-04-20 11:21:33.809 14475-14475/org.briarproject.hotspot E/TEST: requestGroupInfo attempt: 4 2021-04-20 11:21:33.815 14475-14475/org.briarproject.hotspot E/TEST: received networkName: DIRECT-nH-D561ZZO3Ey 2021-04-20 11:21:33.815 14475-14475/org.briarproject.hotspot E/TEST: received passphrase: S3Hy7r1K 2021-04-20 11:21:34.816 14475-14475/org.briarproject.hotspot E/TEST: requestGroupInfo attempt: 5 2021-04-20 11:21:34.822 14475-14475/org.briarproject.hotspot E/TEST: received networkName: DIRECT-nH-D561ZZO3Ey 2021-04-20 11:21:34.822 14475-14475/org.briarproject.hotspot E/TEST: received passphrase: S3Hy7r1KI had to turn wifi off and on again to resolve this, but as far as I can tell there was a functional hotspot, it's just that the app didn't accept it.
@akwizgran From this log and the experience with my devices, the check is there to ensure a functional hotspot. The SSID requested was
DIRECT-3m-LBoOcm0ZcD, but the group info always returnsDIRECT-nH-D561ZZO3Ey, so also because of a non-matching password, the client would be unable to connect. You can remove the check and try if this is also true for your device.-
Yes, I think
DIRECT-nH-D561ZZO3Eyis probably the hotspot created by the previous instance of the app, before it crashed. But repeatedly requesting the group info won't cause it to change, so the retries don't seem to achieve anything in this case.What might make sense would be to accept the existing network name and password, as long as the network name starts with
DIRECT-. We haven't shown the requested name and password to the client yet, so accepting the existing ones and showing them to the client should be fine, shouldn't it? -
What might make sense would be to accept the existing network name and password, as long as the network name starts with DIRECT-. We haven't shown the requested name and password to the client yet, so accepting the existing ones and showing them to the client should be fine, shouldn't it?
Depends on what you mean by the existing ones? Assuming that the ones we requested will be really the ones the WiFi is using?
In my case (and your two exotic phones), the second attempt to request the group info resulted in the correct information. Only here, the information seems to stay outdated.
-
By existing, I mean that a hotspot was already created by the previous instance of the app, which crashed without removing the hotspot.
When the app was relaunched and requested a different network name, I assume (but haven't verified) that the code hit the
reason == 2check at line 111 and requested the group info. The name and password of the existing hotspot were returned - and as far as I can see, it would have been fine if the app had accepted them and showed them to the client. But instead, the app kept re-requesting the group info because the network name didn't match the one it asked for, and after 5 tries it gave up, so the client wasn't given the chance to connect to the existing hotspot.If we just accept any name that starts with "DIRECT-", without requiring it to be the same name we asked for, I think that would solve the problem we saw on my two exotic devices, where the group info was initially wrong, while also handling the case where a hotspot already exists due to a previous crash.
-
If we just accept any name that starts with "DIRECT-", without requiring it to be the same name we asked for, I think that would solve the problem we saw on my two exotic devices, where the group info was initially wrong, while also handling the case where a hotspot already exists due to a previous crash.
That's correct, but it would not handle the case that I've seen where outdated information (the last hotspot the app had created) was returned in the first attempt and the correct information was only returned with the second attempt.
If we were to return the outdated information there (like we used to do), the client is unable to connect because it is not what the hotspot is actually using.
-
Ah, I see. Maybe in this case, if we reach the max number of retries and the name still doesn't match, we should accept the details that are being returned?
Perhaps we should even do the same if the name doesn't start with "DIRECT-"? So the logic would be "wait up to 5 seconds for a hotspot that looks right, and at the end of that time if we've got a hotspot that doesn't look right, try it anyway".
-
Yes that could work. Implemented in 8c2e2f46
67 68 return webServerState; 68 69 } 69 70 71 @RequiresApi(29) 72 boolean needToAskForEnablingWifi() { 73 return !wifiManager.isWifiEnabled(); 74 } 75 70 76 void startWifiP2pHotspot() { 77 if (!wifiManager.isWifiEnabled() && !wifiManager.setWifiEnabled(true)) { -
Yeah this won't work. We currently enable it for API 30 when the activity starts I think. In the final app, we have to do this differently. We could of course bring the hotspot app for those things in line with how the final implementation looks like. This probably makes sense if we want to continue to use the hotspot app to debug issues that people are reporting later.
