Gluon Mobile : Bluetooth Low Energy, how to connect to a device with a given mac address after scanning? - gluon-mobile

I have a problem to connect to an arduino nano sense 33 BLE. The arduino module contains a profile which has a UUID.
Is it possible to connect to the arduino from the mac address to get profiles UUID then characteristics and finaly read the founded characteristics ?
This is how I proceed :
BleDevice device = new BleDevice();
device.setAddress("E4:38:4F:DA:9F:94"); // MAC ADDRESS of arduino
BleService bleService = BleService.create().get();
bleService.connect(device); // Connect to device
List<BleProfile> list_of_profiles = device.getProfiles(); // Get list of profiles
for(BleProfile profile : list_of_profiles){
System.out.println(profile.getUuid());// display uuid of profiles
//Then get characteristics from profile
//Then read characteristics
}
EDIT :
Scan function updated : This is how I proceed for scanning devices :
public void scan_4_devices(){
long t= System.currentTimeMillis();
long end = t+5000;
System.out.println("searching for devices ...");
BleService.create().ifPresent(ble -> {
ObservableList<BleDevice> ble_list_device = ble.startScanningDevices();
System.out.println("SIZE BEFORE while loop : "+ble_list_device.size());
ble_list_device.addListener((ListChangeListener<BleDevice>) c -> {
while (c.next() && System.currentTimeMillis() < end ) {
System.out.println("SIZE IN while loop : "+ble_list_device.size());
if (c.wasAdded()) {
for (BleDevice device : c.getAddedSubList()) {
System.out.println("Device found: " + device.getName());
}
}
}
ble.stopScanningDevices();
});
});
}
What I'm trying to do is a device search for 5 seconds, if the time is exceeded then I stop the device search. But the application keep crashing, this is the stacktrace after the crash.
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] V/GraalActivity(27191): Activity, get touch event, pcount = 1
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] E/GraalGluon(27191): Native Dalvik layer got touch event, pass to native Graal layer...
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] E/GraalGluon(27191): Native Dalvik layer got touch event, passed to native Graal layer...
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): traceEvent: Pushing TouchState[1,TouchState.Point[id=0,x=688,y=28]] to TouchPipeline[SmallMove]
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): traceEvent: Applying SmallMove to TouchState[1,TouchState.Point[id=0,x=688,y=28]]
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): traceEvent: Set TouchState[1,TouchState.Point[id=0,x=688,y=28]]
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): traceEvent: Set MouseState[x=688,y=28,wheel=0,buttonsPressed=IntSet[212]]
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): PPSRenderer: scenario.effect - createShader: Blend_SRC_IN
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] V/GraalActivity(27191): Activity, get touch event, pcount = 1
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] E/GraalGluon(27191): Native Dalvik layer got touch event, pass to native Graal layer...
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] E/GraalGluon(27191): Native Dalvik layer got touch event, passed to native Graal layer...
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] V/GraalActivity(27191): Activity, get touch event, pcount = 1
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] E/GraalGluon(27191): Native Dalvik layer got touch event, pass to native Graal layer...
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): don't add points, primary = -1
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] E/GraalGluon(27191): Native Dalvik layer got touch event, passed to native Graal layer...
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): traceEvent: Pushing TouchState[1,TouchState.Point[id=0,x=688,y=28]] to TouchPipeline[SmallMove]
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): traceEvent: Applying SmallMove to TouchState[1,TouchState.Point[id=0,x=688,y=28]]
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): traceEvent: Set TouchState[1,TouchState.Point[id=0,x=688,y=28]]
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): traceEvent: Pushing TouchState[0] to TouchPipeline[SmallMove]
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): traceEvent: Applying SmallMove to TouchState[0]
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): traceEvent: Set TouchState[0]
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): traceEvent: Set MouseState[x=688,y=28,wheel=0,buttonsPressed=IntSet[]]
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): searching for devices ...
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] I/GluonAttach(27191): JNI_OnLoad_ble called
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GluonAttach(27191): [BLESERVICE] Initializing native BLE from OnLoad
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalGluon(27191): ATTACH_DALVIK, tid = 27218, existed? 0, dalvikEnv at 0x7db4883200
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GluonAttach(27191): Util :: Load className com/gluonhq/helloandroid/DalvikBleService
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalGluon(27191): ATTACH_DALVIK, tid = 27218, existed? 1, dalvikEnv at 0x7db4883200
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] V/GluonAttach(27191): DalvikBle, init
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] V/GluonAttach(27191): Util <init>
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GluonAttach(27191): Calling Verify Permissions from Attach::Util
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] V/GraalActivity(27191): PermissionRequestActivity::Calling verifyPermissions
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] V/GraalActivity(27191): All requested permissions are granted
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GluonAttach(27191): Verify Permissions from native Attach::Util done
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalGluon(27191): DETACH_DALVIK, tid = 27218, existed = 1, env at 0x7db4883200
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GluonAttach(27191): Initializing native Ble done
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalGluon(27191): ATTACH_DALVIK, tid = 27218, existed? 1, dalvikEnv at 0x7db4883200
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] V/GluonAttach(27191): BLE startScanningPeripherals
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalGluon(27191): DETACH_DALVIK, tid = 27218, existed = 1, env at 0x7db4883200
[mar. mars 30 10:05:13 CEST 2021][INFO] [SUB] D/GraalCompiled(27191): SIZE BEFORE while loop : 0
[mar. mars 30 10:06:21 CEST 2021][INFO] [SUB] --------- beginning of crash
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): ANR in com.hacare.ehacarebox (com.hacare.ehacarebox/com.gluonhq.helloandroid.MainActivity)
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): PID: 27191
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): Reason: Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago. Wait queue length: 34. Wait queue head age: 27397.5ms.)
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): Load: 7.93 / 7.95 / 7.83
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): CPU usage from 126795ms to 0ms ago (2021-03-30 10:04:15.526 to 2021-03-30 10:06:22.321):
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 11% 2867/system_server: 4% user + 7% kernel / faults: 21744 minor 78 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 4% 707/android.hardware.sensors#1.0-service: 1.3% user + 2.6% kernel / faults: 21 minor 5 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 2.4% 623/logd: 0.7% user + 1.7% kernel / faults: 539 minor 1 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 1.8% 23194/kworker/u16:11: 0% user + 1.8% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 2.1% 12638/com.android.bluetooth: 1.2% user + 0.9% kernel / faults: 2319 minor 6 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 2% 3318/com.android.systemui: 1.5% user + 0.5% kernel / faults: 7928 minor 376 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 1.7% 26869/kworker/u16:3: 0% user + 1.7% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 1.6% 23173/kworker/u16:9: 0% user + 1.6% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 1.3% 23196/kworker/u16:14: 0% user + 1.3% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.6% 24530/kworker/u16:0: 0% user + 0.6% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.9% 10811/com.sec.phone: 0.5% user + 0.3% kernel / faults: 171 minor
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.8% 20538/kworker/u16:4: 0% user + 0.8% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.8% 732/surfaceflinger: 0.5% user + 0.3% kernel / faults: 308 minor 16 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.6% 702/android.hardware.graphics.composer#2.1-service: 0.2% user + 0.3% kernel / faults: 96 minor 2 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.5% 695/android.hardware.bluetooth#1.0-service-qti: 0.1% user + 0.3% kernel / faults: 15 minor
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.4% 401/cfinteractive: 0% user + 0.4% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.3% 20184/com.google.android.googlequicksearchbox:search: 0.3% user + 0% kernel / faults: 3639 minor 16 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.3% 3/ksoftirqd/0: 0% user + 0.3% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.3% 80/smem_native_rpm: 0% user + 0.3% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.2% 13990/logcat: 0% user + 0.1% kernel / faults: 29 minor
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 1//init: 0.1% user + 0% kernel / faults: 221 minor
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 23078/mdss_fb0: 0% user + 0.1% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 29022/com.google.android.gms.persistent: 0.1% user + 0% kernel / faults: 543 minor 1 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 15/ksoftirqd/1: 0% user + 0.1% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 29/ksoftirqd/3: 0% user + 0.1% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 123/kswapd0: 0% user + 0.1% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 710/android.hardware.wifi#1.0-service: 0% user + 0.1% kernel / faults: 14 minor
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 273/kgsl_worker_thr: 0% user + 0.1% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 25576/kworker/0:1: 0% user + 0.1% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 7/rcu_preempt: 0% user + 0.1% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 3096/cds_mc_thread: 0% user + 0.1% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 89/kcompactd0: 0% user + 0.1% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 26744/kworker/1:0: 0% user + 0.1% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 3307/com.sec.android.inputmethod: 0% user + 0% kernel / faults: 134 minor 5 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 3927/iod: 0% user + 0% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 10/rcuop/0: 0% user + 0.1% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 95/system: 0% user + 0.1% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0.1% 624/servicemanager: 0% user + 0% kernel / faults: 4 minor
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 26753/kworker/3:2: 0% user + 0% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 22/ksoftirqd/2: 0% user + 0% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 348/irq/305-fts_tou: 0% user + 0% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 25/rcuop/2: 0% user + 0% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 31420/adbd: 0% user + 0% kernel / faults: 642 minor 2 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 701/android.hardware.graphics.allocator#2.0-service: 0% user + 0% kernel / faults: 57 minor
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 717/healthd: 0% user + 0% kernel / faults: 7 minor
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 4187/com.sec.android.app.launcher: 0% user + 0% kernel / faults: 2727 minor 3 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 191/msm_serial_hs_0: 0% user + 0% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 2660/cnss-daemon: 0% user + 0% kernel / faults: 33 minor
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 20087/com.google.android.gms: 0% user + 0% kernel / faults: 875 minor
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 910/wlan_logging_th: 0% user + 0% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 27044/kworker/2:4: 0% user + 0% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 23224/com.android.vending: 0% user + 0% kernel / faults: 910 minor 3 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 18/rcuop/1: 0% user + 0% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 407/irq/181-spdm_bw: 0% user + 0% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 705/android.hardware.memtrack#1.0-service: 0% user + 0% kernel / faults: 12 minor
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 5231/com.samsung.cmh:CMH: 0% user + 0% kernel / faults: 207 minor 3 major
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 26472/com.google.android.apps.docs: 0% user + 0% kernel / faults: 57 minor
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 79/dsps_smem_glink: 0% user + 0% kernel
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] E/ActivityManager( 2867): 0% 83/msm_wa
[mar. mars 30 10:06:25 CEST 2021][INFO] [SUB] W/ActivityManager( 2867): anr : com.hacare.ehacarebox,0
As you can see the size of the list ObservableList<BleDevice> ble_list_device = ble.startScanningDevices(); is 0. This may cause app crash
This is the main class source code:
package com.hacare;
import com.gluonhq.attach.util.Constants;
import com.hacare.views.PrimaryView;
import com.hacare.views.SecondaryView;
import com.gluonhq.charm.glisten.application.MobileApplication;
import com.gluonhq.charm.glisten.visual.Swatch;
import javafx.scene.Scene;
import javafx.scene.image.Image;
import javafx.stage.Stage;
public class Main extends MobileApplication {
public static final String PRIMARY_VIEW = HOME_VIEW;
public static final String SECONDARY_VIEW = "test";
#Override
public void init() {
addViewFactory(PRIMARY_VIEW, () -> new PrimaryView().getView());
addViewFactory(SECONDARY_VIEW, () -> new SecondaryView().getView());
DrawerManager.buildDrawer(this);
}
#Override
public void postInit(Scene scene) {
Swatch.BLUE.assignTo(scene);
scene.getStylesheets().add(Main.class.getResource("style.css").toExternalForm());
((Stage) scene.getWindow()).getIcons().add(new Image(Main.class.getResourceAsStream("/icon.png")));
}
public static void main(String[] args) {
System.setProperty(Constants.ATTACH_DEBUG,"true");
launch(args);
}
}

Ideally, once you connect you should wait for the connection status, before you start asking for the list of profiles.
These are some code snippets you could use:
Device discovery
BleService.create().ifPresent(ble -> {
ObservableList<BleDevice> devices = ble.startScanningDevices();
...
ble.stopScanningDevices();
});
Device connect
BleService.create().ifPresent(ble -> {
device.stateProperty().addListener(new InvalidationListener() {
#Override
public void invalidated(Observable observable) {
if (State.STATE_CONNECTED.equals(device.getState())) {
// device connected, get profiles:
ObservableList<BleProfile> profiles = device.getProfiles();
...
device.stateProperty().removeListener(this);
}
}
});
ble.connect(device);
});
Profile characteristics
ObservableList<BleCharacteristic> characteristics = profile.getCharacteristics();
...
// read characteristic
BleService.create().ifPresent(ble ->
ble.readCharacteristic(device, profile.getUuid(), characteristic.getUuid());
// subscribe characteristic
BleService.create().ifPresent(ble ->
ble.subscribeCharacteristic(device, profile.getUuid(), characteristic.getUuid());
// write characteristic
BleService.create().ifPresent(ble ->
ble.writeCharacteristic(device, profile.getUuid(), characteristic.getUuid(), bytes));
...

Something have changed in the Android BLE Framework, for the moment the solution to fix this issue is to firstly change the attach version to 4.0.12-SNAPSHOT in pom.xml file.
<attach.version>4.0.12-SNAPSHOT</attach.version>
Then by adding the following repository :
<repository>
<id>Snapshots</id>
<url>https://oss.sonatype.org/content/repositories/snapshots/</url>
</repository>
Thanks to José Pereda

Related

Running mvn -Pios client:link results in undefined symbols

I'm new to building iOS apps and gluon-mobile....
I'm trying to build the GluonMobile-SingleViewProject as created by the IntelliJ Gluon Mobile plugin v2.8.5. I have not made any modification to the generated code. The compile phase seems to complete without issue but when running the mvn -Pios client:link command I end up getting a lot of Undefined symbol errors. I think I have followed all the steps in the gluon-mobile document but I can't seem to get past this error.
Below is the build output from the failing link task.
INFO] --- client-maven-plugin:0.1.36:link (default-cli) # gluonmobile-singleviewproject ---
[Wed Feb 24 22:02:11 PST 2021][INFO] ==================== LINK TASK ====================
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] Undefined symbols for architecture arm64:
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] "_JVM_NativePath", referenced from:
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_Get_From_Cache in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] "_JVM_RawMonitorCreate", referenced from:
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_Get_From_Cache in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_Put_In_Cache0 in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] "_JVM_RawMonitorDestroy", referenced from:
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _freeZip in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] "_JVM_RawMonitorEnter", referenced from:
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_Get_From_Cache in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_Put_In_Cache0 in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_Close in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_FreeEntry in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_Lock in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_GetEntry2 in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_GetNextEntry in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] ...
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] "_JVM_RawMonitorExit", referenced from:
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_Get_From_Cache in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_Put_In_Cache0 in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_Close in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_FreeEntry in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_Unlock in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_GetEntry2 in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] _ZIP_GetNextEntry in libzip.a(zip_util.o)
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] ...
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] ld: symbol(s) not found for architecture arm64
[Wed Feb 24 22:02:15 PST 2021][INFO] [SUB] clang: error: linker command failed with exit code 1 (use -v to see invocation)
[Wed Feb 24 22:02:15 PST 2021][SEVERE] Process link failed with result: 1
This is on macOS bigSur (11.0.1) running Xcode 12.4.
Any and all help appreciated.
Thanks,
Joshua

Concatenate several awk command outputs in one command

**I have an input like as follows with many, many rows, and I need to parse all this file into a better format, could be a CSV file or JSON (maybe in the future).
So I need to produce an outcome with columns delimited by a comma, thinking of being able to export the content in CSV file for now.
Get the name files
awk '{ if($2 ~ /A/ ) print $1 }' dir_out
Get all the paths
awt ' /[\\]/ {print}'
Get the size of the files
awk '{ if($3 ~ /^[0-9]/) print $3}'
Right now I have the individual commands to generate the desired result, however I have to find a way to put them in the same line of awk commands, or in a script.
One of the critical points that I have not been able to solve is to make column 1 of the outcome the path that delimits each block, for all the files in the block.
So I starting from this input:
**
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl
R0097A+05.00B-00-QingL.JPG A 6958377 Fri Jun 8 12:53:30 2018
R0097A+05.00B-00-QingLI.JPG A 2794933 Fri Jun 8 12:53:30 2018
R0097A+05.00B-00-QingLO.JPG A 1350397 Fri Jun 8 12:53:30 2018
R0097A+11.00B-00-QingL.JPG A 6997803 Fri Jun 8 12:53:30 2018
R0097A+11.00B-00-QingLI.JPG A 2783151 Fri Jun 8 12:53:30 2018
R0097A+11.00B-00-QingLO.JPG A 1338662 Fri Jun 8 12:53:30 2018
R0097A-00.00B-00-QingL.JPG A 7069740 Fri Jun 8 12:53:30 2018
R0097A-00.00B-00-QingLI.JPG A 2825705 Fri Jun 8 12:53:30 2018
R0097A-00.00B-00-QingLO.JPG A 1369520 Fri Jun 8 12:53:30 2018
Jhumbs.db A 20480 Fri Jun 8 13:14:41 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl
R0098A+05.00B-00-QingL.JPG A 6958377 Fri Jun 8 12:54:30 2018
R0098A+05.00B-00-QingLI.JPG A 2794933 Fri Jun 8 12:54:30 2018
R0098A+05.00B-00-QingLO.JPG A 1350398 Fri Jun 8 12:54:30 2018
R0098A+11.00B-00-QingL.JPG A 6998803 Fri Jun 8 12:54:30 2018
R0098A+11.00B-00-QingLI.JPG A 2783151 Fri Jun 8 12:54:30 2018
R0098A+11.00B-00-QingLO.JPG A 1338662 Fri Jun 8 12:54:30 2018
R0098A-00.00B-00-QingL.JPG A 7069840 Fri Jun 8 12:54:30 2018
R0098A-00.00B-00-QingLI.JPG A 2825705 Fri Jun 8 12:54:30 2018
R0098A-00.00B-00-QingLO.JPG A 1369520 Fri Jun 8 12:54:30 2018
Jhumbs.db A 20480 Fri Jun 8 13:14:41 2018`
ljkhlj
PATH, FILENAME, SIZE, TIMESTAMP
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A+05.00B-00-QingL.JPG, 6958377, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A+05.00B-00-QingLI.JPG, 2794933, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A+05.00B-00-QingLI.JPG, 1350397, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A+11.00B-00-QingL.JPG, 6997803, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A+05.00B-00-QingL.JPG, 6958377, Fri Jun 8 12:54:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A+05.00B-00-QingLI.JPG, 6958377, Fri Jun 8 12:54:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A+05.00B-00-QingLO.JPG, 6958377, Fri Jun 8 12:54:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A+11.00B-00-QingL.JPG, 6958377, Fri Jun 8 12:54:30 2018
Here's a way of combining your awk command into a single script:
#!/bin/bash
awk '
$2 ~ /A/ {print $1; }
/[\\]/ {print}
$3 ~ /^[0-9]/ {print $3}
' "$#"
In general, awk takes multiple /search/ {command} pairs. If /search/ is missing, it defaults to all lines and if {command} is missing, it defaults to print.
Here's the additional logic you need to get your expected results:
#!/bin/bash
awk -v OFS=, '
BEGIN { print "PATH, FILENAME, SIZE, TIMESTAMP" }
/[\\]/ { path=$0 }
$2 ~ /A/ {print path,$1,$3,$4 " " $5 " " $6 " " $7 }
' "$#"
$ cat tst.awk
BEGIN {
OFS = ", "
print "PATH", "FILENAME", "SIZE", "TIMESTAMP"
}
/^ / {
file = $1
size = $3
sub(/^ ([^[:space:]]+[[:space:]]+){3}/,"")
print path, file, size, $0
next
}
{ path = $0 }
$ awk -f tst.awk file
PATH, FILENAME, SIZE, TIMESTAMP
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A+05.00B-00-QingL.JPG, 6958377, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A+05.00B-00-QingLI.JPG, 2794933, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A+05.00B-00-QingLO.JPG, 1350397, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A+11.00B-00-QingL.JPG, 6997803, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A+11.00B-00-QingLI.JPG, 2783151, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A+11.00B-00-QingLO.JPG, 1338662, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A-00.00B-00-QingL.JPG, 7069740, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A-00.00B-00-QingLI.JPG, 2825705, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, R0097A-00.00B-00-QingLO.JPG, 1369520, Fri Jun 8 12:53:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0097\Qingl, Jhumbs.db, 20480, Fri Jun 8 13:14:41 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A+05.00B-00-QingL.JPG, 6958377, Fri Jun 8 12:54:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A+05.00B-00-QingLI.JPG, 2794933, Fri Jun 8 12:54:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A+05.00B-00-QingLO.JPG, 1350398, Fri Jun 8 12:54:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A+11.00B-00-QingL.JPG, 6998803, Fri Jun 8 12:54:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A+11.00B-00-QingLI.JPG, 2783151, Fri Jun 8 12:54:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A+11.00B-00-QingLO.JPG, 1338662, Fri Jun 8 12:54:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A-00.00B-00-QingL.JPG, 7069840, Fri Jun 8 12:54:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A-00.00B-00-QingLI.JPG, 2825705, Fri Jun 8 12:54:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, R0098A-00.00B-00-QingLO.JPG, 1369520, Fri Jun 8 12:54:30 2018
\QJ DaJabase EltraJo\DR0151-populated\DaJa\ASAA Images\k0098\Qingl, Jhumbs.db, 20480, Fri Jun 8 13:14:41 2018

Why does moment-timezone display incorrect GMT offset for some timestamps in same timezone?

I'm using moment-timezone 0.5.1 on node 6.3.0
I'm primarily dealing with the Hong Kong timezone, which has been using GMT+0800 since 1904.
Before that, it was using GMT+0736 since 1885
Yet for some reason, moment-timezone formats some dates near the epoch to display GMT+0900, which doesn't seem to have any basis in history.
I can't seem to find the pattern nor can I reproduce this issue in more recent timestamps.
After epoch
moment.tz(123456780, 'Asia/Hong_Kong').toString() // 'Fri Jan 02 1970 18:17:36 GMT+0800'
moment.tz(1234567800, 'Asia/Hong_Kong').toString() // 'Thu Jan 15 1970 14:56:07 GMT+0800'
moment.tz(5999999999, 'Asia/Hong_Kong').toString() // 'Wed Mar 11 1970 18:39:59 GMT+0800'
moment.tz(9000000000, 'Asia/Hong_Kong').toString() // 'Wed Apr 15 1970 12:00:00 GMT+0800'
moment.tz(9300000000, 'Asia/Hong_Kong').toString() // 'Sat Apr 18 1970 23:20:00 GMT+0800'
moment.tz(12345678000, 'Asia/Hong_Kong').toString() // 'Sun May 24 1970 06:21:18 GMT+0900'
moment.tz(9999999999, 'Asia/Hong_Kong').toString() // 'Mon Apr 27 1970 02:46:39 GMT+0900'
moment.tz(9900000000, 'Asia/Hong_Kong').toString() // 'Sat Apr 25 1970 23:00:00 GMT+0900'
moment.tz(9500000000, 'Asia/Hong_Kong').toString() // 'Tue Apr 21 1970 07:53:20 GMT+0900'
moment.tz(9400000000, 'Asia/Hong_Kong').toString() // 'Mon Apr 20 1970 04:06:40 GMT+0900'
moment.tz(9400000000, 'Asia/Hong_Kong').toString() // 'Mon Apr 20 1970 04:06:40 GMT+0900'
Before epoch
moment.tz(-9000000000000, 'Asia/Hong_Kong').toString() // 'Thu Oct 19 1684 15:36:42 GMT+0736'
moment.tz(-90000000000000, 'Asia/Hong_Kong').toString() // 'Sun Jan 06 -0882 15:36:42 GMT+0736'
moment.tz(-500000000000, 'Asia/Hong_Kong').toString() // 'Sat Feb 27 1954 07:06:40 GMT+0800'
moment.tz(-100000000000, 'Asia/Hong_Kong').toString() // 'Mon Oct 31 1966 22:13:20 GMT+0800'
moment.tz(-900000000000, 'Asia/Hong_Kong').toString() // 'Wed Jun 25 1941 17:00:00 GMT+0900'
moment.tz(-200000000000, 'Asia/Hong_Kong').toString() // 'Sat Aug 31 1963 13:26:40 GMT+0900'
moment.tz(-800000000000, 'Asia/Hong_Kong').toString() // 'Sat Aug 26 1944 02:46:40 GMT+0900'
moment.tz(-900000000000, 'Asia/Hong_Kong').toString() // 'Wed Jun 25 1941 17:00:00 GMT+0900'
It seems like it's also a historical answer, based on Hong Kong's adoption of Daylight Savings Time:
Hong Kong adopted daylight saving measures in 1941. However, in the 1970s, the government found these measures unnecessary as Hong Kong is at a relatively low latitude. The practice was eliminated in 1979.
Taking a quick look at the difference between 1941 and 1942, that seems like where you see the switch between GMT+8 and GMT+9:
moment.tz(new Date('1/1/1941'), 'Asia/Hong_Kong').toString()
// 'Wed Jan 01 1941 16:00:00 GMT+0800'
moment.tz(new Date('1/1/1942'), 'Asia/Hong_Kong').toString()
// 'Thu Jan 01 1942 17:00:00 GMT+0900'

Adding several pods increases iOS app launch time by 10+ seconds

I'm doing an iOS app project in Swift 1.2, using Cocoapods 0.37.2, Xcode 6.3.2. After adding around 8 pods in my project, app launch time greatly increases (around 10 seconds more) on device (iPhone 5). (Note: launch time means the time when you tap the app icon to open the app)
It is so slow iOS terminates it because it doesn't launch in time. The top of the crash log is as follows...
Application Specific Information: com.tryslowappswift failed to launch in time
Elapsed total CPU time (seconds): 27.720 (user 27.720, system 0.000), 68% CPU
Elapsed application CPU time (seconds): 0.074, 0% CPU
Thread 0:
0 dyld 0x1ff0f4c8 ImageLoaderMachOCompressed::rebase(ImageLoader::LinkContext const&) + 456
1 dyld 0x1ff087be ImageLoader::recursiveRebase(ImageLoader::LinkContext const&) + 174
2 dyld 0x1ff07dca ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, bool, ImageLoader::RPathChain const&) + 186
3 dyld 0x1ff012fc dyld::link(ImageLoader*, bool, bool, ImageLoader::RPathChain const&) + 204
4 dyld 0x1ff022d6 dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 2362
5 dyld 0x1fefe222 dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 394
6 dyld 0x1fefe03c _dyld_start + 60
No thread state (register information) available
...
You can test this by:
Note: I have created an example Swift project with all the pods setup in my github repo. You can just clone and run it on your device and see the delay for yourself.
Create a new blank project, nothing in the application:didFinishLaunchingWithOptions: method
Run the app on device and see the app launch very fast.
Stop. Now try adding a Podfile with about 8 pods (no matter big or small the pods are), do pod install.
Just for clarity, this is the Podfile I used...
Podfile
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '8.0'
use_frameworks! # required for Swift pods
pod 'Alamofire', '~> 1.2.1'
pod 'NPReachability', '~> 0.2.0'
pod 'ActionSheetPicker-3.0', '~> 1.6.1'
pod 'SDWebImage', '~> 3.7.2'
pod 'KVNProgress', '~> 2.2.1'
pod 'KeychainAccess'
pod 'JazzHands', '~> 0.2.1'
pod 'DGActivityIndicatorView'
Then run on device again. This time you will notice the 10+ seconds delay, even before application:didFinishLaunchingWithOptions: method is called. No import, no bridging header files, just install the pod into the project and it slows down the launch (-- rage guy meme !!! ---)
I suspect this has to do with Swift 1.2 so I tried on a Objective-C project, but I still experience the same delay. It seems to happen right after a normal pod installation, I have no idea how I can optimize or fix this. :(
UPDATE 1 (27 July 2015):
As pointed by Bryan Musial, I tried adding flags in my schema settings to log load time for each library. I run this on my iPhone 5. Here is the result in Xcode's 'Devices' Window:
Jul 27 13:56:02 Hlung SpringBoard[43] <Warning>: Installed apps did change.
Added: {(
)}
Removed: {(
)}
Modified: {(
"th.in.hlung.TrySlowAppSwift"
)}
Jul 27 13:56:03 Hlung com.apple.debugserver-#(#)PROGRAM:debugserver PROJECT:debugserver-320.2.89
[4964] <Warning>: debugserver-#(#)PROGRAM:debugserver PROJECT:debugserver-320.2.89
for armv7.
Jul 27 13:56:03 Hlung com.apple.debugserver-#(#)PROGRAM:debugserver PROJECT:debugserver-320.2.89
[4964] <Warning>: Connecting to com.apple.debugserver service...
Jul 27 13:56:03 Hlung com.apple.debugserver-#(#)PROGRAM:debugserver PROJECT:debugserver-320.2.89
[4964] <Warning>: Got a connection, waiting for process information for launching or attaching.
Jul 27 13:56:03 Hlung com.apple.debugserver-#(#)PROGRAM:debugserver PROJECT:debugserver-320.2.89
[4964] <Warning>: About to launch process for bundle ID: th.in.hlung.TrySlowAppSwift
Jul 27 13:56:03 Hlung com.apple.xpc.launchd[1] (UIKitApplication:th.in.hlung.TrySlowAppSwift[0x578b]) <Error>: The DisableASLR key is no longer respected. Please remove it.
Jul 27 13:56:03 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:04 Hlung kernel[0] <Notice>: xpcproxy[4965] Container: /private/var/mobile/Containers/Data/Application/6C097544-9C1E-4B73-ACF8-43701FDFC8C2 (sandbox)
Jul 27 13:56:04 Hlung com.apple.debugserver-#(#)PROGRAM:debugserver PROJECT:debugserver-320.2.89
[4964] <Warning>: In completion handler, got pid for bundle id, pid: 4965.
Jul 27 13:56:04 Hlung com.apple.debugserver-#(#)PROGRAM:debugserver PROJECT:debugserver-320.2.89
[4964] <Warning>: Got a connection, launched process /private/var/mobile/Containers/Bundle/Application/9F233F77-63BC-479E-827A-F08C964DE38C/TrySlowAppSwift.app (pid = 4965).
Jul 27 13:56:04 Hlung SpringBoard[43] <Warning>: LICreateIconForImage passed NULL CGImageRef image
Jul 27 13:56:04 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:04 Hlung locationd[4692] <Notice>: Gesture EnabledForTopCLient: 0, EnabledInDaemonSettings: 0
Jul 27 13:56:05 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:05 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:06 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:07 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:08 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:08 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:09 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:10 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:10 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:11 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:12 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:12 Hlung MobileMail[139] <Warning>: Attempting to badge the application icon but haven't received permission from the user to badge the application
Jul 27 13:56:12 Hlung MobileMail[139] <Warning>: Attempting to badge the application icon but haven't received permission from the user to badge the application
Jul 27 13:56:12 Hlung MobileMail[139] <Warning>: Attempting to badge the application icon but haven't received permission from the user to badge the application
Jul 27 13:56:12 Hlung MobileMail[139] <Warning>: Attempting to badge the application icon but haven't received permission from the user to badge the application
Jul 27 13:56:12 Hlung MobileMail[139] <Warning>: Attempting to badge the application icon but haven't received permission from the user to badge the application
Jul 27 13:56:12 Hlung MobileMail[139] <Warning>: Attempting to badge the application icon but haven't received permission from the user to badge the application
Jul 27 13:56:12 Hlung MobileMail[139] <Warning>: Attempting to badge the application icon but haven't received permission from the user to badge the application
Jul 27 13:56:12 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:13 Hlung assistant_service[4931] <Warning>: the local store doesn't allow tasks and we have no default calendar :(
Jul 27 13:56:13 Hlung assistant_service[4931] <Warning>: Error getting NanoAppRegistry workspace info: Error Domain=NSCocoaErrorDomain Code=4099 "The operation couldn’t be completed. (Cocoa error 4099.)" (The connection to service named com.apple.nanoappregistry.workspace was invalidated.) UserInfo=0x17ebf490 {NSDebugDescription=The connection to service named com.apple.nanoappregistry.workspace was invalidated.}
Jul 27 13:56:13 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:14 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:14 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:15 Hlung amfid[4918] <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: dyld: loaded: /usr/lib/libcupolicy.dylib
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: dyld: loaded: /usr/lib/libTelephonyUtilDynamic.dylib
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total time: 13.1 seconds (100.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total images loaded: 149 (128 from dyld shared cache)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total segments mapped: 60, into 1700 pages with 112 pages pre-fetched
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total images loading time: 12.8 seconds (97.9%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total dtrace DOF registration time: 0.17 milliseconds (0.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total rebase fixups: 32,622
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total rebase fixups time: 34.74 milliseconds (0.2%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total binding fixups: 121,320
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total binding fixups time: 116.36 milliseconds (0.8%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total weak binding fixups time: 5.10 milliseconds (0.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total bindings lazily fixed up: 0 of 0
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total initializer time: 118.97 milliseconds (0.9%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: libSystem.B.dylib
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: : 37.57 milliseconds (0.2%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: libBacktraceRecording.dylib
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: : 0.77 milliseconds (0.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: libc++.1.dylib
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: : 0.09 milliseconds (0.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: libobjc.A.dylib
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: : 0.10 milliseconds (0.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: CoreFoundation
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: : 0.88 milliseconds (0.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: vImage
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: : 0.02 milliseconds (0.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: libGLImage.dylib
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: : 0.12 milliseconds (0.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: libFosl_dynamic.dylib
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: : 0.04 milliseconds (0.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: CoreImage
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: : 0.02 milliseconds (0.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: libswiftCore.dylib
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: : 2.14 milliseconds (0.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total symbol trie searches: 43149
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total symbol table binary searches: 0
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total images defining weak symbols: 18
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total images using weak symbols: 44
The most important part is probably this:
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total time: 13.1 seconds (100.0%)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total images loaded: 149 (128 from dyld shared cache)
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total segments mapped: 60, into 1700 pages with 112 pages pre-fetched
Jul 27 13:56:17 Hlung TrySlowAppSwift[4965] <Notice>: total images loading time: 12.8 seconds (97.9%)
It takes a whole 12.8 seconds (97.9%) to load the images. But this empty project doesn't have any image file. I skimmed through the pods and I think they have no significant amount of image file as well. I'm still stuck here.
Comparing to Bryan's result, the same code but run on iPhone 6. The images loading time percentage is also high.
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total time: 1.9 seconds (100.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total images loaded: 148 (127 from dyld shared cache)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total segments mapped: 60, into 1756 pages with 164 pages pre-fetched
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total images loading time: 1.5 seconds (81.6%)
In addition, there's another clue. During the splash screen, there are multiple log lines saying <Error>: SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]. Googling it just reveal that it is some enterprise app problem, which doesn't help me much.
Overall, I'm still stuck. T_T
There are a host of reasons that you might be observing slow application start situations such as low memory or disk space conditions, jailbroken and/or modded device, failed software update in need of a clean install, or even hardware failure. While there isn't a lot to go on with the info you've provided, there are a few things you can take a look at to try and eliminate potential causes.
I've cloned your sample project and tested on devices from iPhone 5 through iPhone 6 Plus and while I have not been able to replicate slow behavior you've observed locally, I have been in situations where both external and internal factors have caused slow startup performance.
First things first, given that we have only a portion of your crashlog you should do some quick verification to make sure we are heading down the right investigative path (Ideally it would be helpful to see the full crashlog) -- As you may or may not know, iOS employs a watchdog process to ensure that iOS apps respond in a reasonable amount of time. When debugging watchdog restrictions are not enforced to allow Xcode the time it needs to establish a live debugging session. Launching as a standalone app, that is, outside of a debugger, Watchdog restrictions are in full effect. Take a look at your crashlog, and check that the Exception Code is the 0x8badf00d (Read: "Ate bad food") -- on 64-bit devices this code will be padded by leading zeros: 0x000000008badf00d
Via TN2151 > Exception Codes:
The exception code 0x8badf00d indicates that an application has been terminated by iOS because a watchdog timeout occurred. The application took too long to launch, terminate, or respond to system events. One common cause of this is doing synchronous networking on the main thread. Whatever operation is on Thread 0: needs to be moved to a background thread, or processed differently, so that it does not block the main thread.
As you've pointed out that application:didFinishLaunchingWithOptions: isn't hit until after waiting that 10+ seconds, it suggests that the delay is occurring while the app's bootstrapping is happening -- your crashlog excerpt generally seems to agree. TrySlowSwiftApp.app's Thread 0 contains only stack frames for the dynamic link editor dyld. You also want to make sure that your crashlog is indicating that Thread 0 is the frame triggering the crash (I can't recall encountering a watchdog crash where Thread 0 wasn't blamed, but I suppose it is possible!). If another thread is being blamed, then we would need to see more about the crashlog you have on-hand.
TN2239 speaks to a host of iOS debugging tools, and includes a section of Environment Variables for the Dynamic Linker - We want to add DYLD_PRINT_STATISTICS with a value of YES to the current run scheme:
We should also enable 'Log Library Loads' in the Scheme's Diagnostic's Editor:
Finally, Xcode's console does not include timestamp information in the In-Xcode Console. You can, however, use Xcode's 'Devices' screen to view the live console with timestamps:
The Environment Variable we added will give you statistical information about what dyld spent its time doing, while the the 'Log Library Loads' options will show you the specific libraries that are attempting to be loaded. Because you are viewing this information in the Device's console you are able to see timestamps associated with each log entry.
Within the dyld statistics output, look for operations that are taking unusually long on your device -- for reference, here's one load on my iPhone 6:
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total time: 1.9 seconds (100.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total images loaded: 148 (127 from dyld shared cache)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total segments mapped: 60, into 1756 pages with 164 pages pre-fetched
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total images loading time: 1.5 seconds (81.6%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total dtrace DOF registration time: 0.06 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total rebase fixups: 32,521
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total rebase fixups time: 24.03 milliseconds (1.2%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total binding fixups: 120,894
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total binding fixups time: 190.36 milliseconds (9.8%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total weak binding fixups time: 1.76 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total bindings lazily fixed up: 0 of 0
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total initializer time: 137.82 milliseconds (7.1%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: libSystem.B.dylib
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 60.11 milliseconds (3.1%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: libBacktraceRecording.dylib
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.39 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: libc++.1.dylib
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.27 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: libobjc.A.dylib
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.03 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: CoreFoundation
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 3.40 milliseconds (0.1%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: vImage
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.31 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: libGLImage.dylib
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.08 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: libFosl_dynamic.dylib
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.01 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: CoreImage
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.57 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: libswiftCore.dylib
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 1.74 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total symbol trie searches: 42394
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total symbol table binary searches: 0
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total images defining weak symbols: 17
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total images using weak symbols: 44
Within the 'dyld: loaded:' lines, take a look at the timestamp accompanying each item that is loaded -- you are looking for places where it takes longer to load the resource than it does with surrounding resources.
Depending on what you find by using these diagnostic tools will help determine what the next diagnostic step should be -- This is left for you to interpret in light of additional information gathered with these steps.
As suggested by others, I'd start by double checking the behavior on a second identical model and OS device -- just to rule out something device specific. If you can replicate it there then you should direct more time to a software investigation, however if it doesn't replicate there, you should direct your time to diagnosing your affected device. A more drastic diagnostic step could involve wiping the device and performing a clean install of iOS. If you do this, I would be prepared to do it at least twice -- the first time not restoring from iCloud or iTunes backup and retesting the launch behavior, then reloading a second time to restore your content to the device.
After some research i found that issue actually not in cocoapods, but in embedded libraries (I was able to reproduce the same issue with carthage).
It's not reproducible on all devices (possibly only on 32bit). And this issue doesn't affect app store builds. And while it makes development slightly slower, it not so harmful.
https://forums.developer.apple.com/message/64556#64556
https://forums.developer.apple.com/message/82399#82399
There is a lot of discussion around this here: https://github.com/artsy/eigen/issues/586
Probably there is one Pod which increases launch time (in worst case more Pods). My advice is to remove one by one the Pods to is if your issue is fixed. Maybe it's easier to create another project to make this test.
If you have a framework or Pod which uses -all_load linker flag, it's a big chance that one to increase a lot the launch time.

ActiveRecord does not respect daylight saving time (DST)?

We're in the timezone Bern, which is +0100. But since we're now in summertime (we have daylight saving time), the current offset is +0200. In my rails app, I set the timezone using a wrapper in the application controller since I need to have user-based timezones:
around_filter :user_timezone
def user_timezone(&block)
Time.use_zone(current_timezone, &block)
end
Now the strange part:
Time.zone.now # 2013-04-10 10:32:56 +0200
# (correct offset)
SomeArModel.first.created_at # 2013-03-28 17:49:59 +0100
# (incorrect offset, no DST)
Is there any explanation for this?
Thats normal behavior, the DST change happened on Sun Mar 31 01:00:00 UTC 2013.
t = Time.mktime(2013, 03, 31, 1, 15, 0)
6.times do
t += 900
u = Time.at(t.to_i).utc
puts t.to_s + " " + u.to_s
end
output:
Sun Mar 31 01:30:00 +0100 2013 Sun Mar 31 00:30:00 UTC 2013
Sun Mar 31 01:45:00 +0100 2013 Sun Mar 31 00:45:00 UTC 2013
Sun Mar 31 03:00:00 +0200 2013 Sun Mar 31 01:00:00 UTC 2013
Sun Mar 31 03:15:00 +0200 2013 Sun Mar 31 01:15:00 UTC 2013
Sun Mar 31 03:30:00 +0200 2013 Sun Mar 31 01:30:00 UTC 2013
Sun Mar 31 03:45:00 +0200 2013 Sun Mar 31 01:45:00 UTC 2013

Resources