Develop Reference

Connecting to Cloud SQL using Compute Engine via JDBC

I cannot connect to my database thru Compute Engine.
Things I have done so far:
Setup my Compute Engine
Connect my Compute Engine to my Cloud SQL
Install and run Cloud Proxy on my Compute Engine
Included the JDBC Jar file on my libs folder
Created the JDBC Connection string
"jdbc:mysql:///?cloudSqlInstance=&socketFactory=com.google.cloud.sql.mysql.SocketFactory;user=&password=";
Added dependency on my Gradle file
-implementation fileTree(dir: 'libs', include: ['*.jar'])
-implementation 'com.google.cloud.sql:mysql-socket-factory-connector-j-8:1.1.0'
Here is the stack trace:
W/System.err: java.sql.SQLNonTransientConnectionException: Cannot
connect to MySQL server on localhost:3,306. W/System.err: Make sure
that there is a MySQL server running on the machine/port you are
trying to connect to and that the machine this software is running on
is able to connect to this host/port (i.e. not firewalled). Also make
sure that the server has not been started with the --skip-networking
flag.
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:110)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:89)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:63)
W/System.err: at
com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:73)
at com.mysql.cj.jdbc.ConnectionImpl.(ConnectionImpl.java:470)
at com.mysql.cj.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:246)
W/System.err: at
com.mysql.cj.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:197)
at java.sql.DriverManager.getConnection(DriverManager.java:569)
at java.sql.DriverManager.getConnection(DriverManager.java:237)
W/System.err: at
com.dedase.dedaseconstruction.ui.login.LoginActivity$GetPatientID.doInBackground(LoginActivity.java:150)
at com.dedase.dedaseconstruction.ui.login.LoginActivity$GetPatientID.doInBackground(LoginActivity.java:136)
at android.os.AsyncTask$2.call(AsyncTask.java:333)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
W/System.err: at java.lang.Thread.run(Thread.java:764)
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'com.mysql.cj.protocol.SocketConnection
com.mysql.cj.protocol.a.NativeProtocol.getSocketConnection()' on a
null object reference
at com.mysql.cj.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:980)
at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:826)
W/System.err: at
com.mysql.cj.jdbc.ConnectionImpl.(ConnectionImpl.java:456)
... 12 more I/Choreographer: Skipped 58 frames! The application may be doing too much work on its main thread. I/zygote: Do full code
cache collection, code=123KB, data=111KB
After code cache collection, code=117KB, data=78KB

This line localhost:3,306. looks really suspicious. Are you sure you don't have a typo somewhere?
You probably came across this repo, and it's not very accurate. I don't have a java client at hand to test it, but I do use Cloud SQL with a different stack and the point of using Proxy is that your app connects to the DB via it as if the DB itself is running locally. Your connection string should not have anything apart from creds and localhost:3306.

Android AssetManager Timeout Exception

We have recently started experiencing a lot of AssetManager Timeout Exception.
Fatal Exception: java.util.concurrent.TimeoutException: android.content.res.AssetManager$AssetInputStream.finalize() timed out after 10 seconds
at android.content.res.AssetManager$AssetInputStream.close(AssetManager.java:565)
at android.content.res.AssetManager$AssetInputStream.finalize(AssetManager.java:598)
at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:190)
at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:173)
at java.lang.Thread.run(Thread.java:818)
We recently updated support lib version to 27.1.1 , playservices to '11.0.4'.
Can't think of any possible reason for the crash appearing recently in large numbers.

Android SQLite exceptions caused by firebase modules

We recently added Firebase to our app and noticed a high increase of SQLite exceptions.
Logs:
android.database.sqlite.SQLiteReadOnlyDatabaseException:
at android.database.sqlite.SQLiteConnection.nativeExecuteForLastInsertedRowId(Native Method:0)
at android.database.sqlite.SQLiteConnection.executeForLastInsertedRowId(SQLiteConnection.java:788)
at android.database.sqlite.SQLiteSession.executeForLastInsertedRowId(SQLiteSession.java:788)
at android.database.sqlite.SQLiteStatement.executeInsert(SQLiteStatement.java:86)
at android.database.sqlite.SQLiteDatabase.insertWithOnConflict(SQLiteDatabase.java:1474)
at bkf.a(:com.google.android.gms.DynamiteModulesC:70)
at bkw.run(:com.google.android.gms.DynamiteModulesC:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)>
or
android.database.sqlite.SQLiteDiskIOException:
at android.database.sqlite.SQLiteConnection.nativeExecuteForLastInsertedRowId(Native Method:0)
at android.database.sqlite.SQLiteConnection.executeForLastInsertedRowId(SQLiteConnection.java:788)
at android.database.sqlite.SQLiteSession.executeForLastInsertedRowId(SQLiteSession.java:788)
at android.database.sqlite.SQLiteStatement.executeInsert(SQLiteStatement.java:86)
at android.database.sqlite.SQLiteDatabase.insertWithOnConflict(SQLiteDatabase.java:1472)
at bkf.a(:com.google.android.gms.DynamiteModulesC:70)
at bkw.run(:com.google.android.gms.DynamiteModulesC:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
In our app we're using SQLite too (multiple threads, single instances of SQLiteOpenHelper), however we don't get any exceptions there.
We also noticed that these exceptions were thrown for about 90% on Sony devices. (SDK 23 and above)
Which comes first in my mind, is a failed SQLite implementation on these devices but I'm not able to reproduce it on our Sony devices, so my questions are:
is this a known Firebase issue?
can anyone confirm my guess?
and well,
what will be a possible workaround
Any help would be appreciated.
Edit:
For sure it's related to SQLiteReadOnlyDatabaseException (it's mentioned in the logs ;) ) but it affects mostly Sony devices and it's not our db which fails but Googles, so I don't think it's duplicated to SQLiteReadOnlyDatabaseException: attempt to write a readonly database

Parse Android SDK ParseUser.getCurrentUser() ANR

Upon upgrading to the latest version of the Parse Android SDK, some of my users are experiencing an issue where our app displays a black screen and eventually ANRs and quits. I was able to get the anr traces.txt and found this:
"main" prio=5 tid=1 WAIT
| group="main" sCount=1 dsCount=0 obj=0x41c1dea0 self=0x41c09768
| sysTid=31669 nice=-11 sched=0/0 cgrp=apps handle=1074811220
| state=S schedstat=( 0 0 0 ) utm=130 stm=12 core=1
at java.lang.Object.wait(Native Method)
- waiting on <0x427b26a8> (a java.lang.Object)
at java.lang.Object.wait(Object.java:364)
at bolts.Task.waitForCompletion(Task.java:132)
at com.parse.ParseTaskUtils.wait(ParseTaskUtils.java:29)
at com.parse.ParseUser.getCurrentUser(ParseUser.java:906)
at com.parse.ParseUser.getCurrentUser(ParseUser.java:893)
at com.ourapp.activities.LauncherActivity.onCreate(LauncherActivity.java:38)
at android.app.Activity.performCreate(Activity.java:5458)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1093)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2376)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2470)
at android.app.ActivityThread.access$900(ActivityThread.java:174)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1307)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:146)
at android.app.ActivityThread.main(ActivityThread.java:5593)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1283)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1099)
at dalvik.system.NativeStart.main(Native Method)
This occurs after a call to:
ParseUser user = ParseUser.getCurrentUser(); in LauncherActivity.
This is occurring only with previously authenticated users and after the app has been closed and relaunched. If they have a fresh install (or cleared data) it does not occur. As far as OS versions and devices it varies quite a bit, but I am able to reproduce it every time with a Samsung Galaxy S4 Mini (GT-I9190) running 4.4.2 KitKat and also with a Samsung Galaxy S4 (GT-I545) running 4.4.2 KitKat. I have seen users report this problem from various manufactures and both pre-lollipop and post lollipop though.
Any ideas??
I have already searched their GitHub for known issues and even searched the Parse Discussion Google Group with no luck. (I have since posted this same question in that group)

Found the issue. We had a custom User class extending ParseUser. I had created a method called "isCurrentUser()" which is also the name of a package method in ParseUser. Lint didn't see a problem with it accordingly, but when Parse goes to retrieve the current user it calls isCurrentUser() in the process and the custom method I created was returning unexpected values to the SDK which then caused an eternal lock on the object in bolts. CRAZY. You wouldn't think the SDK would call my method since it is from a class which extends ParseUser, but it does because the User object being saved is of that same instance.

React Native Android crashes when trying to debug in Chrome

I've got a React Native app that is working for iOS and am trying to get it up and running for Android. I have the app up and running in the emulator and I would like to debug it in Chrome to figure out some issues.
The problem occurs when I open up the in app dev tools and click the Debug in Chrome option the app crashes for a couple seconds and I get an alert message that says "Unfortunately MyApp has stopped." then right after that the app comes back up with the red screen and says "Unable to connect with remote debugger".
I believe I've set up everything as the directions said on this page.
Has anyone seen this kind of issue and if so is there a way to fix it?
Thanks!

Same problem here on Android. I've just started a project with react-native init and begun to follow the Facebook tutorial.
When I run the app without debugging, it works fine. If I enable Debug JS remotely, it crashes after 1 minute (doing nothing).
Testing on Samsung Galaxy S5, react-native-cli 0.2.0, react-native 0.32.1, Windows 7, Chrome 53.
In Android Studio I've found this stacktrace:
09-08 13:25:06.322 31080-3735/com.tutorialproject W/libc: pthread_create failed: couldn't allocate 1064960-byte stack: Out of memory
09-08 13:25:06.322 31080-3735/com.tutorialproject E/art: Throwing OutOfMemoryError "pthread_create (1040KB stack) failed: Try again"
09-08 13:25:06.332 31080-3735/com.tutorialproject E/AndroidRuntime: FATAL EXCEPTION: OkHttp Dispatcher
Process: com.tutorialproject, PID: 31080
java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Try again
at java.lang.Thread.nativeCreate(Native Method)
at java.lang.Thread.start(Thread.java:1063)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:920)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1338)
at okhttp3.ConnectionPool.put(ConnectionPool.java:135)
at okhttp3.OkHttpClient$1.put(OkHttpClient.java:149)
at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:188)
at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:129)
at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:98)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:109)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:124)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:170)
at okhttp3.RealCall.access$100(RealCall.java:33)
at okhttp3.RealCall$AsyncCall.execute(RealCall.java:120)
at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:818)
09-08 13:25:06.372 31080-31080/com.tutorialproject D/SensorManager: unregisterListener ::
09-08 13:25:06.852 31080-31185/com.tutorialproject W/unknown:React: Tried to enqueue runnable on already finished thread: 'native_modules... dropping Runnable.
09-08 13:25:06.852 31080-31185/com.tutorialproject W/MessageQueue: Handler (com.facebook.react.bridge.queue.MessageQueueThreadHandler) {246b7490} sending message to a Handler on a dead thread
java.lang.IllegalStateException: Handler (com.facebook.react.bridge.queue.MessageQueueThreadHandler) {246b7490} sending message to a Handler on a dead thread
at android.os.MessageQueue.enqueueMessage(MessageQueue.java:325)
at android.os.Handler.enqueueMessage(Handler.java:631)
at android.os.Handler.sendMessageAtTime(Handler.java:600)
at android.os.Handler.sendMessageDelayed(Handler.java:570)
at android.os.Handler.post(Handler.java:326)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl.runOnQueue(MessageQueueThreadImpl.java:61)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:31)
at android.os.Looper.loop(Looper.java:145)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:196)
at java.lang.Thread.run(Thread.java:818)
09-08 13:25:06.862 31080-3792/com.tutorialproject W/ContextImpl: Failed to ensure directory: /storage/extSdCard/Android/data/com.tutorialproject/cache
09-08 13:25:11.362 31080-31088/com.tutorialproject W/art: Suspending all threads took: 5.930ms
It's a really simple project, with just a couple of text components, so I'm not doing any request. All the network communication is due the remotely debugging.
Since it's an OutOfMemory problem I've tried to add android:largeHeap="true" to Manifest.xml, but nothing changes. The app reaches the 32Mb consumption and dies.
I've modified the app, so it loads a component with an image 5000 times. With the debugging disabled, the app allocates up to 70Mb and works fine. I can scroll all over the screen and nothing crashes. When I enable the remote debugging, I works for a while, until it tries to allocate more memory and crashes again. I can start again the app with the debugging enabled, and it starts well, but again crashes after a while.
IMHO the React Native remote debugging feature has a problem for allocating new memory (and for some reason it consumes a lot of memory even when the app is stopped).

I had this problem as well (which is why I came across your post). Have you by any chance based your project on the React Native Material Kit Demo? I had, and was having exactly the same problem with crashing when launching devtools.
I've now rebuilt my project from the ground up using react-native init and the problem seems to have gone away.